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Preface 



Nous sommes en 1995. Un industriel du sud-ouest de la France, leader sur un marche 
international, celui de la machine outil dediee au monde de la confection, cherche a con- 
forter le positionnement de ses solutions et a accroitre son avance technologique. II a 
compris qu'au-dela de la qualite et de la precision de ses machines, l'integration au sein 
de ses produits des facteurs de competitivite de ses clients serait un element cle des com- 
petitions a venir. 

Ses systemes, depuis la conception des modeles de vetements, jusqu'a la decoupe des 
pieces de tissus dont le trace a ete prealablement optimise, integrant une « intelligence » 
et une impressionnante sophistication pour le neophyte. Lorsque l'entreprise lance une 
consultation externe afin de se doter d'un outil logiciel de transformation et de conver- 
sion de multiples formats de fielders graphiques, je ne me doute pas une seconde qu'un 
de ses responsables techniques, Pierre Ficheux, a entrepris de faire fonctionner ces diffe- 
rents equipements industriels sous LINUX. De mon cote, apres une premiere analyse de 
l'objet de la consultation, une conviction s'impose : transformer des formats graphiques, 
somme toute repandus, est un travail qui a forcement deja ete realise. Des recherches 
menees en ce sens s'averent fructueuses et l'entreprise integrera avant l'heure des briques 
de logiciels libres dans ses systemes. On est loin a ce moment-la de la notoriete actuelle 
d' Internet, et encore plus de celle de l'Open Source. II devient enfin naturel aujourd'hui 
de s'interroger et de rechercher ce qui a deja ete fait dans le domaine du logiciel, alors 
que ce dernier echappait jusqu' alors a une demarche pourtant banalisee dans le domaine 
scientifique ou artistique. Outre le fait qu'Internet et l'Open Source ont ouvert une voie 
de partage et d'echange sans precedent, des raisons plus profondes de ce retard sont peut- 
etre a rechercher dans la nature meme du logiciel et de son mode de production. II reste 
qu'Internet et l'Open Source ont revolutionne le modele centralise de stockage et d'acces 
a l'information autour duquel etait batie(s) tout aussi bien la bibliotheque d'Alexandrie 
ou les plus volumineuses de nos encyclopedies. L'acces a une information completement 
distribute, voire atomisee au niveau d'un individu a ouvert des champs infinis de partage 
et tend a faire emerger une veritable intelligence collective. La mondialisation ne peut 
pas avoir que des revers ! 

Les methodes de travail dans de nombreux domaines en ont deja ete bouleversees et le 
mouvement est loin d'etre stabilise. Face a une enorme masse d' informations disponi- 
bles, les enjeux evoluent. II s'agit maintenant de trier le grain de l'ivraie, de partager des 
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experiences analogues a ses propres preoccupations, c'est-a-dire ne plus partager simple - 
ment de 1'information mais egalement de la connaissance. Alors que nous sommes au 
tout debut de cette nouvelle histoire, et que les futurs reseaux semantiques du net sont 
encore dans nos laboratoires, rediger un ouvrage de synthese sur un sujet pour le moins 
technique et pointu, reste une bonne facon de faire partager sa passion et son savoir. 



Patrick Benichou 
PDGd' Open Wide 

http://www. openwide. fr 



Avant-propos 



Cet ouvrage a pour but de proposer une methodologie pour la creation de systemes 
embarques avec Linux, en presentant notamment deux etudes de cas tirees du monde 
reel. De nombreux exemples de fichiers de configuration Linux, de codes source en C, 
langage de script Unix ou bien HTML agrementent le tout. S'il faut choisir des qualificatifs 
pour cet ouvrage, les mots concret et pragmatique arrivent largement en tete ! 

L ouvrage se veut aussi independant que possible des produits commerciaux, meme si 
certains peuvent objecter ma preference pour la distribution Red Hat Linux, citee plu- 
sieurs fois dans cet ouvrage. II ne s'agit en rien d'une quelconque publicite deguisee ; 
Red Hat Linux etant, pour diverses raisons, fortement implante dans le monde industriel, 
sa reussite commerciale a tendance a rassurer les industriels qui ne sont pas tous - loin 
s'en faut - des inconditionnels de Linux et de l'Open Source. Dans tous les cas, les con- 
cepts exprimes dans cet ouvrage sont valables quelle que soit la distribution utilisee, ce 
qui est logique puisque nous utilisons systematiquement le noyau Linux officiel. 

A qui s'adresse ce livre ? 

Ce livre s'adresse a un public qui desire se familiariser avec l'utilisation de Linux comme 
systeme embarque, c'est-a-dire integre a un equipement industriel dedie. 

II pourra interesser dans sa premiere partie cadres et decideurs de departements techni- 
ques souhaitant evaluer l'etat de l'art dans ce domaine ainsi que les produits commer- 
ciaux disponibles. 

Une lecture plus poussee de l'ouvrage, dans ses parties suivantes, permettra aux deve- 
loppeurs de realiser de facon pratique l'integration d'un systeme Linux embarque a partir 
de composants standards. 

La lecture complete de l'ouvrage necessite done des notions de programmation en lan- 
gage C et en langage de script Unix (Bourne Shell), ainsi que quelques connaissances 
generales en informatique industrielle. Cependant, un glossaire permettra au lecteur de se 
familiariser avec le vocabulaire specifique bien souvent derive de la langue anglaise. 

Les sources complets des exemples presentes sont disponibles en telechargement sur le 
site d'accompagnement du livre a l'adresse http://www.editions-eyrolles.com. 
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Structure de I'ouvrage 

L'ouvrage est divise en quatre parties. La premiere partie traite des systemes embarques 
en general, de leur champ d'application ainsi que des avantages et inconvenients de l'uti- 
lisation de Linux pour ce type de systeme. Un chapitre decrit le materiel qui peut etre uti- 
lise pour un systeme Linux embarque et un dernier chapitre donne quelques exemples de 
produits commerciaux utilisant Linux comme systeme d' exploitation embarque. Cette 
premiere partie est relativement accessible d'un point de vue technique et ne demande 
pas de connaissances informatiques avancees. 

La deuxieme partie aborde la methodologie de realisation d'un systeme Linux embarque 
a partir de composants standards comme le noyau Linux. Apres une description de la 
structure de Linux, tant au niveau du noyau que de la repartition des fichiers systeme, les 
differentes phases de la creation d'un systeme reduit sont abordees, en particulier la 
comprehension de la structure et du fonctionnement de Linux, 1' optimisation de l'espace 
me moire utilise ou bien la creation de scripts de demarrage. On s' attache a enrichir ce 
systeme minimal par une description detaillee des composants lies aux reseaux, a 
1' authentification des utilisateurs ou bien a 1' installation du systeme sur des peripheriques 
speciaux comme les memoires flash. 

Dans une troisieme partie, on detaille certaines mises en oeuvre particulieres, notamment 
pour les systemes temps-reels, et Ton montre comment concevoir des interfaces graphiques 
lorsqu'elles sont necessaires. Dans cette nouvelle edition, cette troisieme partie contient 
egalement un chapitre consacre aux environnements de developpement croises permet- 
tant de produire et mettre au point des applications embarquees en utilisant Linux ou 
Windows comme systeme de developpement. 

Enfin, la quatrieme partie est constitute de deux etudes de cas appliquant les concepts 
presentes dans la deuxieme partie. Dans le droit til de l'approche concrete qui est privile- 
giee dans cet ouvrage, on se propose de decrire la realisation de la partie logicielle d'une 
platine de lecture/enregistrement de CD audio et fichiers au format MP3, puis d'un 
terminal de consultation Internet utilisant une version reduite du navigateur Netscape 
Communicator. 



Precisions concernant cette deuxieme edition 

Depuis la sortie de la premiere edition de Linux embarque (soit fin 2002), 1' importance 
de Linux et des logiciels libres dans le monde industriel n'a cessee de croitre. De nom- 
breuses entreprises, y compris de grands noms de l'electronique grand public et profes- 
sionnelle, ont adopte Linux comme systeme strategique. Des actions significatives 
comme la creation du CELF {Consumer Electronics Linux Forum) montrent l'avancee 
inexorable de Linux dans ce domaine. Mieux encore, les principaux editeurs des solutions 
embarquees proprietaries ont desormais tous une offre Linux, meme s'ils continuent de 
maintenir et de promouvoir leur gamme classique. Enfin, la presse specialisee s'est fait 
l'echo de cette evolution, ce qui m'a conduit a participer a de nombreuses conferences, 
articles et avis d'experts. 



Avant-propos 



Cet ouvrage a, je l'espere, contribue a la promotion de Linux embarque dans le monde 
francophone et j'ai recu de nombreux courriers de soutien et de suggestion. Ce livre est 
devenu ce a quoi il etait destine, un support concret a la decouverte des technologies 
Linux dans le monde industriel. J'ai dispense depuis trois ans de nombreuses formations 
sur le sujet et ce livre constitue bien evidemment un support de cours directement utilisable. 

En raison de la rapidite de revolution des techniques dans ce domaine, cette nouvelle 
edition etait indispensable : elle est issue des remarques et questions collectees lors des 
nombreuses rencontres avec des utilisateurs. Concretement, un nouveau chapitre est 
consacre a la creation et a l'utilisation des chaines de compilation croisee. De meme, des 
points specifiques concernant la prise en charge du noyau 2.6 sont presents dans les prin- 
cipaux chapitres de l'ouvrage. Le projet BusyBox, qui etait en train de naitre a l'epoque 
de la publication de la premiere version de cet ouvrage, est devenu depuis lors une refe- 
rence incontournable. II est done largement decrit dans cette nouvelle edition. Enfin, le 
chapitre decrivant le projet RTAI, qui est devenu depuis une reference dans le monde 
temps reel, a ete largement mis a jour. Au niveau des exemples de realisation, j'ai porte un 
regard particulier sur la Freebox developpee par Free S A. Le celebre terminal de connexion 
multimedia du premier operateur Internet francais est a ce jour un exemple d'innovation, 
d'autant que e'est un pur produit de l'Hexagone. 

Je profite de cette nouvelle edition pour remercier ceux qui ont contribue de pres ou de 
loin a la diffusion de cet ouvrage. Je remercie de nouveau l'equipe d'Open Wide dont 
l'interet pour Linux embarque ne faiblit pas. Je remercie particulierement Philippe Gerum 
pour son travail sur RTAI et sa maitrise exceptionnelle des divers projets que nous avons 
eus a traiter. J'adresse egalement mes remerciements a Olivier Vine et Alexis Berlemont 
pour leur talent et leur devouement. 

Je remercie Linux Magazine France - et particulierement Denis Bodor - qui m'offre 
regulierement la possibility de m'exprimer sur le sujet ainsi que Patrice Kadionik de 
l'ENSEIRB et Eric Benard de la societe EUKREA avec lesquels la collaboration est 
toujours fructueuse. 

Enfin, je remercie Free SA et Maxime Bizon, pour les informations techniques relatives 
a la Freebox. 

Pierre Ficheux 

Aout 2005 



Introduction 



Qu'est-ce que Linux ? 

Linux est un systeme d' exploitation multitache de la famille Unix. II fut initialement 
developpe sur processeur de type Intel x86 mais il a depuis ete adapte sur un grand nombre 
d' architectures materielles comme les PowerPC, SPARC, Alpha ou meme des processeurs 
specialises et des micro-con troleurs. 

Linux est conforme a la norme Posix, ce qui signifie que les programmes developpes sous 
Linux peuvent etre recompiles facilement sur d'autres systemes d' exploitation compatibles 
Posix. 

Linux est egalement repute pour sa grande interoperabilite, c'est-a-dire qu'il peut facilement 
s'integrer dans un reseau informatique utilisant d'autres systemes d'exploitation. 

Le systeme d'exploitation Linux est libre, le code source des differents composants du 
systeme est disponible gratuitement sur le reseau Internet. Ce meme code source peut 
etre redistribue gratuitement en respectant les regies de la GPL (General Public Licence) 
et de sa variante, la LGPL (Lesser General Public Licence), toutes deux explicitees plus 
loin dans le present chapitre ; elles sont definies par la FSF (Free Software Foundation) 
pour le projet GNU. Le principe general de la GPL est celui de la conservation de la 
liberie, chacun devant au moins redistribuer ce qu'il a recu. 

Qu'est-ce que I'Open Source 1 ? 

Voici un rappel en neuf points de ce qui caracterise les produits Open Source. 

1 . Libre redistribution. La licence ne doit pas empecher de vendre ou de donner le logi- 
ciel en tant que composant d'une distribution d'un ensemble contenant des program- 
mes de diverses origines. La licence ne doit pas exiger que cette vente soit soumise a 
l'acquittement de droits d'auteur ou de royalties. 



1. La definition du concept d'Open Source est disponible sur http://www.opensource.org. La traduction francaise est 
disponible sur http://www.linux-france.org. 
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2. Inclusion du code source. Le programme doit inclure le code source, et la distribu- 
tion sous forme de code source, comme sous forme compilee, doit etre autorisee. 
Quand une forme d'un produit n'est pas distribute avec le code source correspon- 
dant, il doit exister un moyen clairement indique de telecharger le code source, 
depuis l'lnternet, sans frais supplementaires. Le code source est la forme la plus 
adequate pour qu'un programmeur puisse modifier le programme. II n'est pas auto- 
rise de proposer un code source rendu difficile a comprendre. II n'est pas autorise de 
proposer des formes intermediaries, comme ce qu'engendre un preprocesseur ou un 
traducteur automatique. 

3. Autorisation de travaux derives. La licence doit autoriser les modifications et les 
travaux derives, et leur distribution sous les memes conditions que celles qu' autorise 
la licence du programme original. 

4. Integrite du code source de I'auteur. La licence ne peut restreindre la redistribution 
du code source sous forme modifiee que si elle autorise la distribution de fichiers 
patches au cote du code source dans le but de modifier le programme au moment de 
la construction. La licence doit explicitement permettre la distribution de logiciel 
construit a partir du code source modifie. La licence peut exiger que les travaux 
derives portent un nom different ou un numero de version distinct de ceux du logiciel 
original. 

5. Pas de discrimination entre les personnes ou les groupes. La licence ne doit operer 
aucune discrimination a l'encontre de personnes ou de groupes de personnes. 

6. Pas de discrimination entre les domaines d' application. La licence ne doit pas limi- 
ter le champ d' application du programme. Par exemple, elle ne doit pas interdire 
l'utilisation du programme pour faire des affaires ou dans le cadre de la recherche 
genetique. 

7. Distribution systematique de la licence. Les droits attaches au programme doivent 
s'appliquer a tous ceux a qui le programme est redistribue sans que ces parties ne 
doivent remplir les conditions d'une licence supplementaire. 

8. La licence ne doit pas etre specifique a un produit. Les droits attaches au programme 
ne doivent pas dependre du fait que le programme fait partie d'une distribution logicielle 
specifique. Si le programme est extrait de cette distribution et utilise ou distribue selon 
les conditions de la licence du programme, toutes les parties auxquelles le programme 
est redistribue doivent beneficier des droits accordes lorsque le programme est au 
sein de la distribution originale de logiciels. 

9. La licence ne doit pas contaminer d'autres logiciels. La licence ne doit pas apposer 
de restrictions sur d'autres logiciels distribues avec le programme qu'elle couvre. Par 
exemple, la licence ne doit pas exiger que tous les programmes distribues grace au 
meme medium soient des logiciels « Open Source ». 
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Un peu d'histoire : de Minix a Linux 



Le debut d'une longue histoire... 

Tout a commence le 3 juillet 1991, dans le groupe de discussion comp.os.minix, 
Internet voit apparaitre le message suivant : 

From: torvalds@kl aava. Helsinki .FI (Linus Benedict Torvalds) 

Newsgroups: comp.os.minix 

Subject: Gcc-1.40 and a posix-question 

Message-ID: <1991Jul3. 100050. 9886@kl aava. Hel sinki .FI> 

Date: 3 Jul 91 10:00:50 GMT 

Hello netlanders, 

Due to a project I'm working on (in minix). I'm interested in the posix 
standard definition. Could somebody please point me to a (preferably) 
machine-readable format of the latest posix rules? Ftp-sites would be nice. 

Puis, le 25 aout 1991 : 

From: torvalds@kl aava. Helsinki .FI (Linus Benedict Torvalds) 

Newsgroups: comp.os.minix 

Subject: What would you like to see most in minix? 

Summary: small poll for my new operating system 

Message-ID: <1991Aug25. 205708. 9541@klaava. Helsinki . FI> 

Date: 25 Aug 91 20:57:08 GMT 

Organization: University of Helsinki 

Hello everybody out there using minix - 

I'm doing a (free) operating system (just a hobby, won't be big and 

professional like gnu) for 386(486) AT clones. This has been brewing 

since april, and is starting to get ready. I'd like any feedback on 

things people like/dislike in minix. as my OS resembles it somewhat 

(same physical layout of the file-system (due to practical reasons) 

among other things) . 

I've currently ported bash(1.08) and gcc(1.40), and things seem to work. 

This implies that I'll get something practical within a few months, and 

I'd like to know what features most people would want. Any suggestions 

are welcome, but I won't promise I'll implement them :-) 

Linus (torvalds@kruuna. hel sinki .fi ) 

PS. Yes - it's free of any minix code, and it has a multi-threaded fs. 

It is NOT portable (uses 386 task switching etc), and it probably never 

will support anything other than AT-harddisks, as that's all I have :-(. 

En voici, plus ou moins fidelement, une traduction dans la langue de Moliere : 

Bonjour aux utilisateurs du reseau, 

Pour un projet sur lequel je travaille actuellement (MINIX), je suis interesse par 
des informations concernant le standard Posix. Quelqu 'un peut-il m 'indiquer un 
pointeur vers une version electronique des dernieres specifications Posix ? Une 
adresse FTP serait le mieux. 
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Puis : 

Bonjour a tous les utilisateurs de MINIX, 

Je developpe un systeme d' exploitation libre (juste pour le plaisir, ce n' est pas un 
gros projet comme GNU) pour les compatibles AT 386(486). 

Cela infuse depuis le mois d'avril et ca commence a fonctionner. J'aimerais avoir 
votre avis concernant ce que vous aimez/n 'aimez pas dans le systeme d' exploita- 
tion MINIX, vu que mon systeme lui ressemble (en particulier sur certaines cou- 
ches physiques du systeme defichiers et ce entre autres pour des raisons pratiques. 

J'ai a ce jour porte bash(1 .08) et gcc(1.40), et ca a Vair de fonctionner. 

Cela signifie que j'aurai quelque chose d'utilisable dans quelques mois et j'aime- 
rais savoir ce que desirent les utilisateurs. Toute suggestion est bienvenue mais je 
ne peux pas promettre de pouvoir la realiser. 

Linus (torvalds@kruuna.helsinki.fi) 

P.-S. Oui, c'est independant de tout code MINIX, et cela utilise un systeme de 
fichiers multi-thread. Ce n 'est PAS portable (utilisation du changement de contexte 
386) et cela ne supportera vraisemblablement jamais autre chose que les disques 
durs AT, vu que je n'ai que ca. 

Suite a cet article, la communaute des developpeurs s'est interessee de pres au 
jeune etudiant finlandais dont le prenom etait effectivement predestine a la realisa- 
tion d'un clone d'Unix. S'il s'etait prenomme Robert ou Marcel, son travail 
n'aurait peut etre pas connu le meme succes. . . 



Le systeme Minix que cite Linus Torvalds est egalement un systeme d' exploitation de la 
famille Unix developpe par le professeur Andrew S. Tanenbaum de l'universite d'Ams- 
terdam (ast@cs.vu.nl) et destine a des tins pedagogiques. 

A l'epoque de la parution de cet article, le monde Unix est emprisonne dans des solutions 
proprietaries, le plus souvent du fait des fabricants de materiel. Ces stations de travail ou 
serveurs sont tres onereuses, au moins dix fois le cout actuel du PC le plus puissant 
d'aujourd'hui. De meme, le systeme d' exploitation diffuse avec ce materiel n'est jamais 
livre avec son code source car il est developpe, le plus souvent, a partir de code source 
soumis a licence et provenant de la societe AT&T (American Telegraphs & Telephones, 
http://www.att.com), createur du systeme d' exploitation Unix. 

II existe cependant deja a l'epoque une version plus libre d'Unix, developpee a l'univer- 
site de Berkeley en Californie sous le nom 6.' UNIX BSD (Berkeley Software Distribu- 
tion), et ce depuis la fin des annees 1970. Ce produit majeur apportera a la communaute 
Unix des fonctionnalites essentielles comme la gestion du reseau TCP/IP. Cette version 
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est egalement a l'origine d'autres Unix libres ou produits commerciaux toujours utilises 
aujourd'hui comme FreeBSD, NetBSD ou OpenBSD. 

UNIX BSD est initialement adapte par le constructeur SUN Microsystems (http://www.sun 
.com) pour les premieres versions de son systeme SunOS. Pousse par la pression commer- 
ciale, SUN decidera plus tard d'utiliser la version AT&T connue sous le nom de System V R4 
et commercialisee par SUN sous 1' appellation SOLARIS. 

Le principal probleme de l'epoque est le rapport cout/performances du materiel disponible, 
ce qui contraint a l'utilisation de stations proprietaires pour des systemes d' exploitation 
evolues tels qu'Unix. Les systemes personnels tels que les IBM PC 386/486 sont de ce 
fait condamnes a utiliser des systemes d' exploitation peu performants comme MS-DOS 
parfois associe a l'interface graphique MS-Windows 3. II en resulte que les clones d'Unix 
disponibles sur 386/486 comme MINIX ou bien MWC-COHERENT ne sont pas utilisables 
dans des environnements industriels. 

Le fait est qu'un an et demi apres l'apparition d'une premiere version 0.01 du noyau 
Linux qui tient sur un poster, le noyau 0.99 sort en decembre 1992. Ce dernier est deja tres 
complet, tres stable, avec un support reseau TCP/IP de bonne qualite et une collection de 
pilotes de peripheriques deja non negligeable. Des distributions Linux comme la SLS ou 
la Slackware sont deja disponibles. Ces dernieres regroupent les composants Linux 
essentiels ainsi qu'une procedure d'installation facilitant la mise en place d'un systeme 
pour les non-specialistes. 



What is GNU ? Gnu is Not Unix 

II serait cependant faux de croire que le logiciel libre n'existait pas avant Linux. Deja, 
dans les annees 1980, Richard M. Stallman (http://www.stallman.org), un chercheur en 
intelligence artificielle du M.I.T (Massachusetts Institute of Technology), initialise un 
projet de developpement de composants logiciels libres. De par son environnement 
culturel, Stallman s'oriente naturellement vers 1' environnement Unix, non qu'il consi- 
dere ce systeme comme parfait mais plutot parce qu'il est selon ses dires not so bad (pas 
si mal). Le projet porte par ailleurs le nom de GNU (http://www.gnu.org), hommage au 
quadrupede cornu et velu du meme nom (« gnou », en francais), mais surtout definition 
recursive et typique de 1' humour informaticien qui ne fait rire personne sauf les informa- 
ticiens eux-memes : 

What is GNU ? Gnu is Not Unix. 

Richard Stallman en profita pour mettre en place un nouveau type de licence de distribu- 
tion appelee GPL (General Public Licence), utilisant le principe du copyleft par opposi- 
tion au copyright des licences proprietaires. La description complete de la licence est 
assez longue et disponible en annexe de cet ouvrage. II est cependant fortement recom- 
mande de prendre connaissance de cette licence si vous desirez utiliser Linux ou un logi- 
ciel Open Source pour un projet industriel. Outre les elements legaux indispensables, 
cette lecture vous apportera des elements cles pour la comprehension de la philosophic 
du logiciel libre. 
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La GPL se differencie d'autres licences, plus permissives, permettant 1' appropriation 
d'un code originellement libre mais pouvant ensuite etre capture par un editeur de logi- 
ciels. La licence LGPL {Lesser GPL) est similaire a la GPL sur les points suivants : 

• Le copy left, qui interdit a quiconque de s'approprier le code source d'un logiciel et de 
ses derives modifies a partir du moment ou l'original a ete diffuse sous GPL ou LGPL. 
Cela oblige en particulier a redistribuer le code source des modifications d'un compo- 
sant deja place sous GPL ou LGPL. 

• La disponibilite des modifications : si vous effectuez une correction sur un programme 
et si vos corrections sont acceptees par le mainteneur, vous n'avez normalement done 
plus a vous soucier de ces corrections pour les versions futures. 

En revanche, la LGPL permet d'effectuer une edition de liens de code proprietaire avec 
des bibliotheques sous LGPL. Cette extension de la licence est fondamentale car elle 
permet la disponibilite sous Linux d' applications proprietaires qui utilisent des biblio- 
theques LGPL indispensables comme la glibc (GNU C library). 

En raison des limitations materielles citees precedemment, les composants du projet 
GNU sont utilises sur des systemes Unix proprietaires, ce qui permet deja a l'epoque de 
s'affranchir de certains outils pay ants mais pas forcement de meilleure qualite diffuses 
par les constructeurs. Le meilleur exemple en est le couple gec/gdb (Gnu C Compiler/ 
Gnu DeBugger) considere comme un des meilleurs compilateurs/debogueur sur le mar- 
che et surtout assurant une parfaite compatibilite entres les differentes plates-formes de 
developpement. 

Stallman lancera egalement le projet GNU-Hurd, focalise sur le developpement d'un sys- 
teme d' exploitation tres novateur. Le projet est toujours actif actuellement mais n'a pas 
acquis une maturite industrielle comparable a celle de Linux ou d'autres clones libres 
d'Unix. 

II est important de noter que le travail de Linus Torvalds a d'emblee porte sur la partie 
noyau du systeme d' exploitation. Les autres utilitaires, comme gec, gdb ou toutes les 
commandes Unix classiques, sont en fait empruntes au projet GNU ou a d'autres projets 
de logiciel libre comme 1' interface graphique X Window System. 

Le fait est qu'aujourd'hui Linux est connu par certaines menageres, meme de plus de cin- 
quante ans et que GNU Test beaucoup moins alors qu'un systeme tournant sous Linux 
contient beaucoup plus de code du projet GNU que du projet Linux lui-meme. 

On peut raisonnablement se demander comment un jeune etudiant finlandais de vingt- 
deux ans put ainsi damer le pion a un vieux routard du logiciel libre deja celebre comme 
l'etait et Test toujours Stallman. Les raisons sont multiples. 

La premiere est chronologique : le projet Linux demarre au debut des annees 1990, a 
l'aube de l'explosion du reseau Internet et de l'economie dite nouvelle qui y est associee. 
La facilite de developpement des projets communautaires comme Linux est augmentee 
de maniere exponentielle grace a ce nouveau moyen de communication. Ayant debute 
son projet dix ans plus tot, Richard Stallman n'a pu profiter des avancees d'Internet. 
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La deuxieme raison tient a la personnalite des deux hommes. Stallman est une figure 
emblematique du logiciel fibre mais que, peut etre a raison, certains considerent comme 
un extremiste du fibre. Son allure caricaturale de « gourou » exotique, ses positions plus 
que tranchees et ses coups de gueule spectaculaires ne pouvaient que susciter la mefiance 
du monde industriel. 

Linus Torvalds est au contraire un garcon pose, calme et bien peigne, auquel les lunettes 
elegantes du futur gendre ideal sieent a ravir. Dote d'un sens inne de la communication et 
d'un charisme qui le positionnent naturellement dans un role de leader, il est aujourd'hui 
presente par la presse comme celui qui revela au monde une nouvelle conception du logi- 
ciel. Ce dernier point provoqua d'ailleurs la fureur de Stallman qui demanda instamment 
que le systeme dit Linux fut rebaptise GNU-Linux. 

La version 1.0 officielle sort en mars 1994 et Linux est d'ores et deja utilise pour des 
applications industrielles. La version 1.2 voit le jour en 1995. A ce moment, l'industrie 
informatique est de plus en plus sous l'emprise hegemonique des solutions Microsoft 
avec la sortie du fameux Window 95 et la consolidation de la version serveur du systeme 
de Microsoft Windows NT. Empetre dans les architectures proprietaires tres couteuses et 
les guerres fratricides entre les differentes versions de systeme d'exploitation, le monde 
Unix est promis a une mort proche. 

Pour T instant, ce jeune Linux n'est pas encore, selon 1' expression de Microsoft, sur les 
ecrans radar, mais tout le monde est deja convaincu que le salut d'Unix ne peut venir que 
de la. Les versions 2.0 et 2.2 de Linux sortent respectivement en juillet 1996 et Janvier 
1999. D'ores et deja, de nombreuses distributions facilitant l'installation du systeme ont 
vu le jour, le support de peripheriques sensibles comme les cartes graphiques est de bien 
meilleure qualite, et l'ont peut dire qu'a partir de 1999, les pilotes de peripheriques sont 
fournis desormais par les fabricants de materiel, ce qui enterine 1' adoption de Linux en 
tant que systeme d'exploitation majeur. 

Les chiffres d'equipement des serveurs vendus durant l'annee 1999 donnent 24,4 % a 
Linux, 37,8 % a Windows NT, 19,2 % a Novell Netware et seulement 15,2 % a tous les 
autres Unix. 

Un autre element determinant des annees 1999 et 2000 est 1' adoption de Linux par les 
grands editeurs professionnels de progiciels comme les systemes de base de donnees, les 
logiciels de sauvegarde et autres composants essentiels de l'industrie informatique. 
Linux y perd la purete d'un systeme informatique entierement fibre puisqu'il est desor- 
mais frequent de faire cohabiter Linux avec des versions proprietaires de logiciels com- 
merciaux. 

Dans les cas les plus classiques d'utilisation de Linux, il est cependant possible de n'utiliser 
que des composants fibres comme le serveur HTTP Apache, les langages de programmation 
Perl, PHP ou Python, ou bien les systemes de base de donnees MySQL et PostgreSQL 
pour ne citer que les plus connus. 

Outre la sortie du dernier noyau 2.4 en Janvier 2001, les annees 2000 et 2001 sont marquees 
par l'utilisation de plus en plus frequente de Linux en tant que solutions industrielles 



Introduction 



embarquees, c'est-a-dire optimisees pour l'execution de taches donnees. Meme si la folie 
boursiere associee aux jeunes societes proches de Linux est retombee comme un souffle, 
ce dernier est aujourd'hui bien implante dans le monde des serveurs. 

IDC prevoit une croissance de Linux de 28,4 % dans ce domaine, contre 21,4 % pour 
Windows NT, et Linux se prepare une entree fracassante a tous les niveaux d'un monde 
industriel ou sa fiabilite, ses performances, sa facilite d' adaptation, sont autant d'avan- 
tages decisifs face a des solutions proprietaires. 



Premiere partie 



Systemes embarques, 
generalites 




Cette partie s'attachera tout d'abord a decrire Ies concepts fonda- 
mentaux necessaires a la comprehension de la problematique des 
systemes embarques. Nous decrirons ensuite les avantages et incon- 
venients du choix de Linux par rapport a ses principaux concur- 
rents dans Ie domaine. Nous citerons de nombreux exemples de 
realisations industrielles et embarquees a partir de Linux ainsi 
qu'un echantillon des solutions materielles les mieux adaptees. 
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Les logiciels embarques et leurs 

domaines d'application 

Qu'est-ce qu'un logiciel embarque ? 

Un logiciel embarque (embedded software en anglais) est un programme utilise dans un 
equipement industriel ou un bien de consommation. La difference essentielle avec un 
logiciel classique tient a la complete integration du logiciel embarque dans cet equipe- 
ment : il n'a pas de raison d'etre en dehors de l'equipement pour lequel il a ete concu. On 
parle egalement de logiciel integre ou dedie. Historiquement, cette notion est anterieure 
a l'idee meme du logiciel tel qu'il est communement defini aujourd'hui : le programma- 
teur mecanique du lave-linge ou de l'arrosage automatique fait partie des logiciels dedies 
et personne n'achete un tel equipement pour son logiciel lui-meme, mais bien evidem- 
ment pour la qualite des services que remplit l'equipement. 

Cette logique a perdure et doit etre prise en compte par les concepteurs des logiciels 
embarques : l'equipement est valorise uniquement par son aspect fonctionnel et un bon 
logiciel integre le sera a un tel point qu'on finira par l'oublier ! Dans le cas de logiciels 
de tres petite taille destines a des taches tres specifiques, on parle d'ailleurs en anglais de 
deeply embedded software, ce qui peut se traduire par logiciel profondement enfoui. 

Quelles sont les caracteristiques d'un tel logiciel ? 

Les points suivants permettent de caracteriser un logiciel embarque : 



Cible 



Son domaine d' action est limite aux fonctions pour lesquelles il a ete cree. Concevoir un 
lave-linge qui fait le cafe n'est jamais une bonne idee... 



Systemes embarques, generalites 

Premiere partie 



Fiable et securise 



Le logiciel necessite une grande fiabilite car il est destine a un fonctionnement complete - 
ment autonome. Lorsqu'un pieton traverse la route, il n'est pas de bon ton que le logiciel 
de gestion de TABS (Anti Blocking System) de votre vehicule « s'excuse » de ne pouvoir 
fonctionner car une erreur fatale a interrompu le fonctionnement du programme. Cette 
contrainte en dit long sur le fosse qui existe par rapport aux logiciels classiques. 

Maintenable dans le temps 

Dans la majorite des domaines industriels, et en dehors du logiciel classique, la duree de 
vie des produits est longue de par des obligations legales ou du moins commerciales qui 
obligent l'industriel a maintenir le produit pendant une dizaine d'annees, cas de l'indus- 
trie automobile. Dans le cas d'industries plus sensibles comme l'aeronautique, le mili- 
taire ou le spatial, cette duree peut etre doublee. II est done indispensable que le logiciel 
embarque soit maintenable durant toute la duree de vie du produit en cas de decouverte 
de probleme de fonctionnement majeur. 

Specifique 

L'interface de dialogue avec l'utilisateur est specifique : dans la majorite des cas, un tel 
logiciel n' utilise pas les interfaces classiques clavier/souris propres a la micro-informatique. 
S'ils existent, les peripheriques d'affichage sont souvent limites a des panneaux de petite 
taille de type LCD (Liquid Crystal Display), et les peripheriques d'entree a quelques 
boutons poussoirs ou autres composants inhabituels dans rinformatique traditionnelle. 
Tout cela, combine aux contraintes d' optimisation citees precedemment, necessite une 
approche tres materielle, proche de l'electronique. Les concepteurs de logiciels embar- 
ques sont rarement des informaticiens purs, plus souvent des etres hybrides entaches de 
neurones d'electroniciens. De ce fait, ils sont habitues a des environnements de travail 
spartiates, pour ne pas dire arides, ce qui accentue encore le fosse avec le developpeur 
standard habitue a un confort presque indecent. 

Optimise 

Le plus souvent, mais ce n'est pas obligatoire, ce logiciel est de petite taille si on le com- 
pare aux volumes demesures atteints par les logiciels classiques multi-usages comme en 
bureautique. La raison en est double : 

• La necessite de fiabilite citee precedemment cohabite mal avec un volume demesure : 
plus on ecrit de lignes de codes, plus on a de chances que celles-ci contiennent des 
bogues. 

• Le logiciel est souvent embarque dans des equipements produits a grande echelle sur 
lesquels le moindre ecart de cout du a un embonpoint imprevu du logiciel peut avoir 
de fortes repercussions. 
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L' optimisation est egalement importante au niveau du temps de reponse. Le consomma- 
teur verra d'un tres mauvais ceil une soi-disant evolution technologique qui ralentit le 
fonctionnement de l'equipement. Outre l'exemple evident du freinage cite precedem- 
ment, un autre exemple marquant est celui des assistants personnels ou PDA (Personal 
Digital Assistant) : le logiciel Palm OS plus rustique que son rival Windows CE du pour- 
tant hegemonique Microsoft lui tient la dragee haute, tout simplement parce que 
l'homme d'affaires presse Test suffisamment pour etre agace d'attendre le deroulement 
du menu Demarrer. 

Alors que la micro-informatique a debute avec 1 kilo-octet de memoire vive et un sys- 
teme sur 8 Ko de ROM (le ZX-81 !), il n'est pas rare aujourd'hui de voir des adolescents 
pester contre le PHI de l'annee precedente qui n'affiche pas assez vite les formes plantu- 
reuses de Lara Croft. 

Helas, cette banalisation des performances a quelques effets pervers : 

• Elle masque les imperfections et la faible optimisation (voire les bogues) de certains 
produits car comme dit le sage : « Software becomes slower faster than hardware 
becomes faster », ce qui peut se traduire par : « Le logiciel devient plus lent avant que 
le materiel ne devienne plus rapide », mais ca sonne mieux en anglais. 

• Elle incite a une consommation effrenee de hardware, ce qui annule malheureusement 
la baisse des couts de celui-ci. 

• Elle donne des mauvaises habitudes au programmeur qui, fort de ses 512 Mo de RAM, 
30 Go de disque et Pentium XXX a YYY GHz, ne comprend pas pourquoi la classe 
Java 'Hello World!' prend tellement de temps a s'executer alors qu'il a suffi de cliquer 
sur le bouton generate code. 

• Elle masque le fonctionnement reel du systeme, ce qui fait que Ton ne sait plus trop, 
des centaines de bibliotheques et des dizaines de packages, lesquels sont vraiment utiles 
pour l'utilisation courante de la machine. En revanche, en cas de verification du disque 
apres un crash systeme, on se rend compte que les packages sont bien la et que ces 
quatre cafes bus, en attendant, etaient tres bons. 

L'exemple le plus flagrant de cette course a la consommation est bien entendu les diffe- 
rentes moutures du systeme Microsoft Windows et les applications associees pour les- 
quelles chaque version est systematiquement accompagnee d'une augmentation de taille, 
compensee bien sur par 1' achat de quelques giga-octets de disque dur ou d'une barrette 
de memoire supplementaire. 

Logiciel embarque ou systeme embarque ? 

Nous avons pour l'instant parle de logiciel embarque alors qu'il est frequent d'entendre 
la terminologie de systeme embarque. Cette terminologie designe le plus souvent un sys- 
teme d' exploitation, version complexe et multi-usage du concept de logiciel. Si nous 
revenons a la notion de systeme d' exploitation telle qu'elle est communement admise, 
reference est alors faite a un ensemble de programmes permettant : 
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1. de gerer les ressources de l'installation materielle en assurant leurs partages entre un 
ensemble plus ou moins grand d'utilisateurs ; 

2. d' assurer un ensemble de services en presentant aux utilisateurs une interface mieux 
adaptee a leurs besoins que celle de la machine physique. 

La premiere reaction, legitime, est de considerer qu'un systeme d' exploitation est a 
priori beaucoup trop complexe et surdimensionne pour remplir les taches decrites dans la 
section precedente. C'est vrai dans certains cas de specificite extreme du logiciel a 
embarquer ou de fortes contraintes materielles mais il est egalement vrai que 1' ameliora- 
tion des performances du materiel permet dans un grand nombre de cas d'utiliser un sys- 
teme d' exploitation adapte au lieu d'un simple logiciel dedie. 

Les avantages de l'utilisation d'un systeme d' exploitation sont les suivants : 

• Comme dans le cas du developpement de logiciel classique, il affranchit le deve- 
loppeur de l'applicatif embarque d'un travail d' adaptation tres proche du materiel, ce 
qui permet de diminuer le temps de developpement et done les couts. Lecriture du 
support de standards du marche comme les bus PCI ou USB est extremement lourde 
en cas de non-utilisation d'un systeme d' exploitation. Dans le cas d'un systeme, ce 
travail est realise par une autre equipe specialisee ou un fournisseur externe. 

• Si le systeme d' exploitation utilise est suffisamment repandu, il permet aux applica- 
tions industrielles et embarquees de beneficier des memes avancees technologiques 
que les applications classiques. C'est ainsi qu'il est aujourd'hui possible d'utiliser 
dans des systemes reduits des protocoles de communication herites de l'informatique 
classique et du multimedia. Nous pouvons citer par exemple l'utilisation generalisee 
du protocole TCP/IP et de ses derives comme HTTP (Hyper Text Transfer Protocol) ou 
FTP (File Tranfer Protocol) dans des procedures de communication entre des systemes 
classiques et des micro-systemes dedies. La complexite des protocoles de communica- 
tion et done le temps de mise au point d'une version specifiquement adaptee pour un 
logiciel embarque rendent ce choix techniquement et economiquement tres hasardeux. 
L'utilisation d'un systeme d' exploitation qui inclut un support natif et largement 
debogue de ces protocoles est alors un bien meilleur choix car le support d'un proto- 
cole se reduira le plus sou vent a l'ajout d'un module ou d'un programme externe deja 
teste, compare aux nombreuses heures de mise au point necessaires a la mise en place 
d'une version « maison ». 



Remarque 

HTTP est le protocole utilise pour le transfert des donnees multimedias entre un serveur web et un poste client 
equipe d'un navigateur ou browser. Plus ancien, le protocole FTP est lui reserve au simple transfert de fichier. 
L'utilisation dans I'embarque de ces protocoles standards en remplacement de protocoles proprietaires facilite 
I'interoperabilite des systemes. 

Les systemes d' exploitation fournissent en general un environnement de developpe- 
ment facilitant la mise au point des programmes dans un contexte beaucoup plus 
accueillant et performant que le systeme cible - celui sur lequel est cense tourner le 
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programme definitif. Un exemple industriel celebre est celui de la PlayStation2 de 
SONY. Les developpeurs de jeux ne pouvant disposer de la console definitive imme- 
diatement, ils utiliserent un environnement de developpement base sur Red Hat Linux 
permettant de simuler le fonctionnement de la console sur des stations de travail. 

Remarque 

Une etude de cas, dans la troisieme partie de I'ouvrage, decrira egalement une methode simple utilisee pour 
developper une application embarquee controlant un ecran LCD sans pour cela disposer de ce materiel. 

A contrario, le principal inconvenient de 1' utilisation d'un veritable systeme d' exploita- 
tion proche d'un systeme classique est la taille memoire necessaire. II est bien evident 
que, si l'espace disponible est reduit a quelques centaines d'octets pour accomplir une 
tache rudimentaire, un vrai systeme d' exploitation ne s'imposera pas. 

Les champs d'application 

Comme nous l'avons precise au debut de ce chapitre, le champ d'application des syste- 
mes embarques est tres vaste. Le fait est qu'il est d'ailleurs de plus en plus vaste car de 
nombreuses fonctions autrefois realisees par des systemes mecaniques ou du moins ana- 
logiques sont aujourd'hui remplacees par des composants logiciels, meme rudimentaire s. 

Au niveau applicatif, les systemes embarques se retrouvent historiquement sur les sujets 
suivants (liste non exhaustive) : 

• controle de processus industriels ; 

• commande numerique, machines outils ; 

• automobile ; 

• telecommunications : centraux telephoniques, telephones mobiles ; 

• reseaux informatiques : routeurs, systemes ; 

• peripheriques informatiques : imprimantes, photocopieurs ; 

• aeronautique et transports en general ; 

• systemes medicaux. 

A titre d' exemple, on peut citer des produits comme : 

• l'autoradio MP3 de chez EMPEG (http://www.empeg.com) ; 

• les magnetoscopes numeriques comme TiVo (http://www.tivo.com) ou Replay TV (http:// 
www.replaytv.com). (Ces produits seront un peu plus detailles en fin de premiere partie 
de I'ouvrage) ; 

• les platines CD/MP3, dont un prototype de developpement sera presente comme etude 
de cas dans la troisieme partie de cet ouvrage. 
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D'un point de vue technique, le champ d'application peut etre grossierement divise en 
deux grandes families : 

• le controle de processus sans contrainte ou a faible contrainte temps reel ; 

• le controle de processus avec contrainte temps reel. 

Cette separation est fondamentale car elle determinera completement le choix des com- 
posants logiciels a utiliser. Dans le premier cas, on pourra envisager l'utilisation d'un 
systeme d' exploitation derive d'un systeme classique comme Linux. L' adaptation se 
situera principalement au niveau du developpement de pilotes de peripheriques et de 
P optimisation du systeme en taille ou en performances. Dans le second cas, les contraintes 
materielles necessiteront l'utilisation de composants specialises, soit un logiciel specifique, 
soit un systeme d' exploitation dit temps reel {Real Time Operating System ou RTOS). 
Les definitions et comparaisons des deux types de systemes seront approfondies dans la 
section suivante. 

Le domaine de l'equipement grand public avait echappe aux systemes embarques 
d'abord pour des raisons de cout du materiel. De plus, ces equipements fonctionnaient de 
maniere isolee et n'avaient jusqu'ici aucun lien avec les reseaux informatiques. Le deve- 
loppement des services sur Internet a incite les industriels a integrer des produits initiale- 
ment peu communicants dans des environnements en reseau. Cette integration necessite 
l'utilisation de protocoles de communication herites de Pinformatique, et done le plus 
souvent d'integrer des couches logicielles supportant ces protocoles. 

On peut meme citer des produits aussi peu excitants que les refrigerateurs dont les modeles 
futurs pourront integrer des fonctionnalites reseau, un navigateur Internet et done un systeme 
d' exploitation evolue. A titre d'exemple, on peut citer le ScreenFridge de chez Electrolux 

( http://www. electrolux. co. uk/screenfhdge) . 

L'emergence de ces produits est egalement liee a Papparition d'un concept ne de Peco- 
nomie du reseau : V appliance. Cette notion est difficilement traduisible directement en 
frangais mais afin d'eclairer le lecteur nous presentons ci-apres un appliance specialise 
dans la fabrication du cafe : 




Figure 1-1 

Appliance de fabrication du cafe 
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Qu'est-ce qu'un appliance ? 

Le site de la version frangaise du Jargon informatique (http ://www.linux-france.org/prj/jargonf) en donne la 
definition suivante : « Se dit de toutes sortes de machines dont la principale caracteristique est de pouvoir 
etre (theoriquement) simplement branchees pour fonctionner immediatement de maniere parfaitement 
operationnelle. Le plus fou, c'est que cette promesse est souvent tenue ! Serveur applicatif en frangais ». 



La notion de serveur applicatif decoule d'un besoin tres simple du marche informatique 
qui est celui de considerer les services logiciels (serveur web, serveur FTP, base de don- 
nees) comme des elements modulaires et facilement administrables le plus souvent grace 
a l'outil universel qu'est le navigateur Internet. Si le besoin de service se fait sentir, nul 
besoin d' installer un systeme d' exploitation complique sur lequel il faudra installer un 
logiciel qui Test encore plus. Dans un appliance, l'administrateur ne saura pas forcement 
quel type de systeme d' exploitation est utilise dans la « boite noire ». II suffit d'ajouter 
un element, souvent sous forme de rack et de choisir une adresse IP sur le reseau local a 
moins que l'element en question ne sache la determiner tout seul grace a un serveur 
DHCP ou BOOTP. Tout cela est effectue grace a des afficheurs LCD en face avant ou un 
navigateur Internet execute sur une machine tierce dont le systeme d' exploitation 
importe egalement peu. 



Rappel 

Les protocoles DHCP (Dynamic Host Configuration Protocol) et BOOTP (BOOTstrap Protocol) permettent a des 
systemes connectes a un reseau de type TCP/IP de recuperer automatiquement une adresse IP sans interven- 
tion d'un operateur ni configuration. Cette adresse leur sera affectee par un se/veurDHCP ou BOOTP. 



On voit done que la notion d' appliance est fortement liee a celle d'un systeme embarque 
de par les contraintes de facilite d' installation et d' utilisation, de transparence et de surete 
de fonctionnement. De ce fait, la notion d' appliance depasse les limites du monde infor- 
matique. En effet, si le systeme home cinema du futur inclut un navigateur web ou meme 
un serveur web utilisable par les autres postes multimedias du reseau local, il y aura de 
moins en moins de difference entre ce serveur familial et les millions d' autres presents 
sur Internet. Les logiciels utilises seront souvent les memes et le systeme d' exploitation 
sera egalement le meme : Linux ! 



Remarque 

Nous rejoignons ici le concept des milliards de nceuds d'lnternet predit par le chercheur frangais Christian 
Huitema dans son ouvrage de vulgarisation Et Dieu crea /'Internet (Editions Eyrolles, 1995) : « II y a deja des 
microprocesseurs, en fait de tout petits ordinateurs dans bien d'autres endroits [...]. D'ici quelques annees, le 
developpement et les progres de I'electronique aidant, ces microprocesseurs deviendront sans doute de vrais 
ordinateurs elabores et il sera tout a fait raisonnable de les connecter a Internet » [Huitema 95]. 
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Typologie des systemes embarques 

Comme nous l'avons rapidement signale dans la section precedente, les systemes embar- 
ques se divisent en deux families : les systemes dits temps reel et les autres. Nous allons 
expliquer dans cette section les differents modes de partage du temps dans ces deux types 
de systemes d' exploitation. 

Temps partage et temps reel 

La gestion du temps est un des problemes majeurs des systemes d'exploitation. La raison 
en est simple : les systemes d'exploitation modernes sont tous multitdches, or ils utilisent 
du materiel base sur des processeurs qui ne le sont pas, ce qui oblige le systeme a parta- 
ger le temps du processeur entre les differentes taches. Cette notion de partage implique 
une gestion du passage d'une tache a l'autre qui est effectuee par un ensemble d'algorifh- 
mes appele ordonnanceur (ou scheduler). 

Un systeme d'exploitation classique comme Unix, Linux ou Windows utilise la notion de 
temps partage, par opposition au temps reel. Dans ce type de systeme, le but de 1' ordon- 
nanceur est de donner a l'utilisateur une impression de confort d'utilisation tout en assu- 
rant que toutes les taches demandees sont finalement executees. Ce type d'approche 
entraine une grande complexite dans la structure me me de 1' ordonnanceur qui doit tenir 
compte de notions comme la regulation de la charge du systeme ou la date depuis 
laquelle une tache donnee est en cours d' execution. De ce fait, on peut noter plusieurs 
limitations par rapport a la gestion du temps. 

Tout d'abord, la notion de priorite entre les taches est peu prise en compte, car l'ordon- 
nanceur a pour but premier le partage equitable du temps entre les differentes taches du 
systeme (on parle de quantum de temps). Notez que sur les differentes versions d'Unix 
dont Linux, la commande nice permet de modifier la priorite de la tache lors du lance - 
ment. 

Ensuite, les differentes taches doivent acceder a des ressources dites partagees, ce qui 
entraine des incertitudes temporelles. Si une des taches effectue une ecriture sur le disque 
dur, ce dernier n'est plus disponible pour les autres taches a un instant donne et le delai 
de disponibilite du peripherique n'est pas previsible. 



Rappel 

La gestion des ressources partagees entre differentes taches se fera grace a des composants appeles 
semaphores. 



En outre, la gestion des entrees/sorties peut generer des temps morts, car une tache peut 
etre bloquee en attente d'acces a un element d' entree/sortie. 

La gestion des interruptions recues par une tache n'est pas optimisee. Le temps de 
latence - soit le temps ecoule entre la reception de 1' interruption et son traitement - n'est 
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pas garanti par le systeme. Par comparaison, le temps de latence dans le cas d'un systeme 
temps reel est sou vent inferieur a 100 microsecondes. 

Enfin, 1' utilisation du mecanisme de memoire virtuelle peut entrainer des fluctuations 
dans les temps d' execution des taches. 



Rappel 

La memoire virtuelle permet au systeme de disposer d'une quantite de memoire, superieure a la quantite de 
memoire vive reellement disponible. Le systeme pourra pour cela utiliser des espaces dedies sur la memoire de 
masse afin de simuler une memoire virtuelle. Linconvenient en sera bien sur une forte degradation des perfor- 
mances. 



Toutes ces limitations font que le temps de reponse d'un systeme classique n'est pas 
garanti. 



Remarque 

Une grande partie des systemes industriels ne necessitent pas forcement une gestion stricte du temps, ce qui 
permettra d'utiliser les systemes classiques avec peu de modifications. Si la tache du systeme est bien definie, 
on pourra en particulier connaitre a I'avance I'espace memoire utilise et s'affranchir de I'utilisation de memoire 
virtuelle. 



Le cas des systemes temps reel est different. II existe un grand nombre de definitions 
d'un systeme dit temps reel, et la plupart d'entre elles sont contradictoires. Une definition 
simple d'un tel systeme pourra etre la suivante : 

« Un systeme est dit temps reel lorsqu'il est soumis a des contraintes de temps et qu'il y 
repond dans un intervalle acceptable » [Blachier 2000], 

ou bien : 

« Un systeme temps reel est une association logiciel/materiel ou le logiciel permet, entre 
autres, une gestion adequate des ressources materielles en vue de remplir certaines taches 
ou fonctions dans des limites temporelles bien precises » [Mabilleau 2001]. 

II est evident que la structure de ce systeme dependra de ces fameuses contraintes. On 
pourra diviser les systemes en deux categories : 

• Les systemes dits a contraintes souples ou molles {soft real time). Ces systemes accep- 
tent des variations dans le traitement des donnees de l'ordre de la demi-seconde (ou 
500 ms) ou la seconde. On peut citer l'exemple des systemes multimedias : si quel- 
ques images ne sont pas affichees, cela ne met pas en peril le fonctionnement correct 
de l'ensemble du systeme. Ces systemes se rapprochent fortement des systemes 
d' exploitation classiques a temps partage. 

• Les systemes dits a contraintes dures {hard real time) pour lesquels une gestion stricte 
du temps est necessaire pour conserver l'integrite du service rendu. On citera en guise 
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d'exemples les controles de processus industriels sensibles comme la regulation des 
centrales nucleaires ou les systemes embarques utilises dans l'aeronautique. 

Les systemes a contraintes dures doivent repondre a trois criteres fondamentaux : 

1. Le determinisme logique : les memes entrees appliquees au systeme doivent produire 
les memes effets. 

2. Le determinisme temporel : une tache donnee doit obligatoirement etre executee 
dans les delais impartis ; on parle d'echeance. 

3. hafiabilite : le systeme doit etre disponible. Cette contrainte est tres forte dans le cas 
d'un environnement embarque car les interventions d'un operateur sont tres difficiles 
ou meme impossibles. Cette contrainte est independante de la notion de temps reel 
mais la fiabilite du systeme sera d'autant plus mise a l'epreuve dans le cas de 
contraintes dures. 

En resume, on peut dire qu'un systeme temps reel doit etre previsible (predictible), les 
contraintes temporelles pouvant s'echelonner entre quelques microsecondes et quelques 
secondes. 



Attention 

Un systeme temps reel n'est pas forcement plus rapide qu'un systeme a temps partage. 
satisfaire a des contraintes temporelles prevues a I'avance. 



devra en revanche 



La petite experience decrite ci-apres met en evidence la difference entre un systeme clas- 
sique et un systeme temps reel. Considerons la configuration decrite sur la figure 1-2 
[Blachier 2000] : 



Ordinateur 



Port parallele 



Cornpteur 



TO 



Figure 1-2 

Test comparatif temps reel/temps partage 



Le but de 1' experience est de generer un signal periodique sortant du port parallele du PC. 
Le temps qui separe deux emissions du signal sera mesure a l'aide d'un compteur. Le but 
est de visualiser revolution de ce delai en fonction de la charge du systeme. La frequence 
initiale du signal est de 25 Hz (Hertz), ce qui donne une demi-periode T/2 de 20 ms 
(milli-secondes). 
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Sur un systeme classique, cette demi-periode varie de 17 a 23 ms, ce qui donne une varia- 
tion de frequence entre 22 Hz et 29 Hz. La figure 1-3 ci-apres donne la representation 
graphique de la mesure sur un systeme non charge, puis a pleine charge : 
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Figure 1-3 

Representation sur un systeme classique 

Sur un systeme temps reel, la demi-periode varie entre 19,990 ms et 20,015 ms, ce qui 
donne une variation de frequence de 24,98 Hz a 25,01 Hz. La variation est done beau- 
coup plus faible. La figure 1-4 donne la representation graphique de la mesure : 
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Figure 1-4 

Representation sur un systeme temps reel 



Lorsque la charge est maximale, le systeme temps reel assure done une variation de 
± 0,2 Hz, alors que la variation est de + 4 Hz dans le cas d'un systeme classique. 

Cette experience met en evidence 1' importance des systemes temps reel pour certaines 
applications critiques. En revanche : 

• Un systeme temps reel aura un plus faible rendement, a materiel egal, qu'un systeme 
classique. 



Systemes embarques, generalites 

Premiere partie 

• L' utilisation d'un systeme temps reel pourra poser des problemes de compatibilite 
materielle car les pilotes de peripheriques adaptes ne sont pas toujours fournis par le 
constructeur - en raison d'une trap faible diffusion. 

• Pour la meme raison, les API (Application Programming Interfaces, interfaces de pro- 
grammation d' applications) et outils de developpement d'un systeme classique seront 
souvent plus conviviaux que ceux d'un systeme temps reel. 

Preemption et commutation de contexte 

La notion de preemption intervient a deux niveaux : 

• celui de la gestion du multitache, 

• celui du noyau du systeme. 

Dans un systeme utilisant un multitache preemptif, l'ordonnanceur pourra interrompre 
une tache suite, par exemple, a la reception d'une interruption. Les vrais systemes multi- 
taches utilisent ce type de technologie, citons Unix, Linux, Windows NT. Dans un sys- 
teme multitache non preemptif, la tache ne peut etre interrompue par le systeme ; elle 
doit directement demander 1' intervention de l'ordonnanceur. On parle egalement de 
multitache collaboratif. Le systeme Windows 3.1 1 est un multitache collaboratif. 

Le noyau (kernel) est le composant principal d'un systeme d' exploitation multitache 
moderne. Dans un tel systeme, chaque tache (ou processus) est decomposed en threads 
(processus leger ou tache legem) ; ce sont des elements de programmes, chacun etant 
capable d'executer une portion de code dans un meme espace d'adressage. Chaque 
thread est caracterise par un contexte local contenant la priorite du thread, ses variables 
locales ou l'etat de ses registres. Le passage d'un thread a un autre est appele changement 
de contexte (context switch). Ce changement de contexte sera plus rapide sur un thread 
que sur un processus car les threads d'un processus evoluent dans le meme espace 
d'adressage, ce qui permet le partage des donnees entre les threads d'un meme processus. 
Dans certains cas, un processus ne sera compose que d'un seul thread et le changement 
de contexte s'effectuera sur le processus lui-meme. 

Remarque 

Dans le cas du systeme Linux, le meme appel systeme cione( ) est utilise pour creer un processus ou un 
thread. La primitive forkO de creation de processus correspond en fait a cioneto, sigcld| copyvm). 

Dans le cas d'un systeme temps reel, le noyau est dit preemptif, c'est-a-dire qu'un thread 
peut etre interrompu par l'ordonnanceur en fonction du niveau de priorite, et ce arm de 
permettre l'execution d'un thread de plus haut niveau de priorite. On peut ainsi affecter 
les plus hauts niveaux de priorite a des taches dites critiques par rapport a l'environne- 
ment reel controle par le systeme. La verification des contextes a commuter est realisee 
de maniere reguliere par l'ordonnanceur en fonction de l'horloge logicielle interne du 
systeme, ou tick systeme. 
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Dans le cas d'un noyau non preemptif, un thread sera interrompu uniquement dans le cas 
d'un appel au noyau ou d'une interruption externe. La notion de priorite etant tres peu 
utilisee (excepte avec la commande ni ce dans le cas de Linux), c'est le noyau qui decide 
ou non de commuter le thread actif en fonction d'un algorithme complexe. 



Resume 

On ne peut pas prevoir a I'avance le temps de reponse d'un systeme classique. Un systeme temps reel a en 
revanche un comportement previsible, mais souvent un rendement moins eleve qu'un systeme classique, a 
configuration egale. Dans la majorite des cas, un systeme classique assorti d'une etude prealable de dimension- 
nement et de securisation permettra de satisfaire aux contraintes de temps reel « mou », et la programmation 
sur un tel systeme sera plus aisee. 



Le tableau ci-apres presente une synthese de la comparaison entre un systeme a temps 
partage et un systeme temps reel. 



Tableau 1-1. Comparaison des criteres temps reel et partage 



Critere 


Temps partage 


Temps reel 


Global 


Avoir la meilleure capacite 
de traitement 


Etre previsible 


Temps de reponse 


Doit etre bon en moyenne 


Doit etre bon meme dans le pire 
des cas, la moyenne n'a pas 
d'importance 


Comportement a la charge 


Confortable pour I'utilisateur 


Stabilite et respect des contraintes 
de temps 



Extensions Posix 



La complexite des systemes et l'interoperabilite omnipresente necessitent une standardi- 
sation de plus en plus grande tant au niveau des protocoles utilises que du code source 
des applications. Meme si elle n'est pas obligatoire, l'utilisation de systemes conforme a 
Posix est de plus en plus frequente. 

Posix est l'acronyme de Portable Operating System Interface ou interface portable pour 
les systemes d'exploitation. Cette norme a ete developpee par 1'IEEE (Institute of Elec- 
trical and Electronic Engineering) et standardised par l'ANSI {American National 
Standards Institute) et 1'ISO {International Standards Organisation). 

Le but de Posix est d'obtenir la portabilite des logiciels au niveau de leur code source. Le 
terme de portabilite est un anglicisme derive de portability, lui-meme reserve au jargon 
informatique. Un programme qui est destine a un systeme d'exploitation qui respecte 
Posix doit pouvoir etre adapte a moindre frais sous n'importe quel autre systeme Posix. 
En theorie, le portage d'une application d'un systeme Posix vers un autre doit se resumer 
a une compilation des sources du programme. 
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Remarque 

Le concept de portability est tres important d'un point de vue economique en termes de developpement logiciel 
car le portage des applications genere souvent des frais enormes pour les editeurs de logiciel, ce qui explique 
que certains logiciels existent uniquement pour les systemes d'exploitation les plus repandus. Bob Scheifler, un 
des responsables du projet X Window System, a declare a ce sujet : « II n'existe pas de logiciel portable, seule- 
ment des logiciels portes. » 

Posix a initialement ete mis en place pour les systemes de type Unix mais d'autres syste- 
mes d'exploitation comme Windows NT sont aujourd'hui conformes a Posix. Le stan- 
dard Posix est divise en plusieurs sous-standards dont les principaux sont les suivants : 

• IEEE 1003.1-1990 : Posix partie 1 : Interface de programmation (API) systeme. 
Definition d'interfaces de programmation standards pour les systemes de type Unix, 
connue egalement sous 1' appellation ISO 9945-1. Ce standard contient la definition de 
ces fonctions (bindings) en langage C. 

• IEEE 1003.2-1992 : interface applicative pour le shell et applications annexes. Definit 
les fonctionnalites du shell et commandes annexes pour les systemes de type Unix. 

• IEEE 1003.1b-1993 : interface de programmation (API) temps reel. Ajout du support 
de programmation temps reel au standard precedent. On parle egalement de Posix.4. 

• IEEE 1003.1c-1995 : interface de programmation (API) pour le multithreading. 

Pour le sujet qui nous interesse, la plupart des systemes d'exploitation utilisables dans les 
technologies de l'embarque sont conformes partiellement ou totalement au standard 
Posix. C'est le cas en particulier des systemes temps reel LynxOS (http://www.lynux- 
works.com) et QNX (http://www.qnx.com). Quant a Linux, sa conformite par rapport a 
Posix 1003.1b est partielle dans sa version standard et requiert l'application de modifica- 
tions (ou patch) sur les sources du noyau. II est cependant probable que la version standard 
sera conforme dans le courant de l'annee 2002. 

Definition de I'empreinte memoire 

Par definition, I'empreinte est la faille memoire occupee par le systeme. Meme si ce n'est 
pas une obligation, les systemes embarques ont en general une faible empreinte, et ce afin 
d'optimiser le systeme tant au niveau des couts que de la securite de fonctionnement. La 
reduction de I'empreinte memoire est la tache principale d'un developpeur de systeme 
embarque car elle a un impact economique enorme sur l'industrialisation finale du 
produit. Plusieurs chapitres de la deuxieme partie de l'ouvrage seront consacres a ce 
probleme. 

Le tableau 1-2 donne une idee des empreintes memoire, me moires vive (RAM) et morte 
(ROM), en fonction du type d' application. Les valeurs donnees sont indicatives et des 
technologies specifiques comme les disques memoires (ramdisk) ou bien les systemes 
de fichiers compresses (compressed filesystem) pourront modifier fortement le rapport 
RAM/ROM. 
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Tableau 1-2. Empreinte memoire en fonction du type d'application 



Produit 


Serveur 


Desktop 


PC emb. 


Emb. 
gros 


Emb. 
moyen 


Emb. 
typique 


Profondement 
enfoui 


RAM 
en Mo 


128 ou + 


128-32 


64-16 


32 a 8 


8a2 


4 a 0,1 


Moinsde0,1 


ROM 
en Mo 


Plusieurs 
milliers 


Plusieurs 
centaines 


64 ou 
plus 


32 a 8 


8a2 


2 a 0,5 


0,5 a 0,1 





Remarque 

La notion de ROM citee ici Test par opposition a celle de RAM. Tout ou partie de la memoire ROM sera souvent 
constitute de memoire flash reinscriptible. 



Les deux premieres colonnes ne concernent en general pas le monde des applications 
embarquees. II faut cependant faire la difference entre l'empreinte memoire du systeme 
d' exploitation et celle des donnees. Dans certains cas, on pourra par securite avoir un 
systeme d' exploitation reduit a quelques mega-octets (Mo) sur une memoire morte et 
un disque dur, ou autre peripherique de stockage de masse de plusieurs dizaines ou cen- 
taines de giga-octets destine a recevoir les donnees. 

Les systemes dits profondement enfouis (deeply embedded) sont souvent a la limite de 
l'utilisation d'un systeme d' exploitation par rapport a un logiciel embarque dedie. 
Cependant, les applications de ce type sont le plus souvent embarquees dans des equipe- 
ments portables de faible volume comme des telephones mobiles qui necessitent de plus 
en plus de fonctions de communications avancees, tout en conservant une taille memoire 
raisonnable en rapport avec leur large diffusion. Des systemes comme QNX ou eCos 
(voir pour eCos : http://ecos.sourceware.org et http://www.ecoscentric.com/) serontbien adaptes 
a ce type d'application. 

Les langages utilises 

Pour des raisons evidentes de contraintes materielles, le langage assembleur a longtemps 
ete le choix de predilection des technologies de 1' embarque car il permettait a la fois 
d'optimiser la taille du code genere mais aussi ses performances. La gestion d'un projet 
complexe ecrit en assembleur est cependant difficile et revolution des performances du 
materiel et des compilateurs permet aujourd'hui de se tourner vers des solutions plus 
confortables. Les langages C et C++ restent aujourd'hui le choix favori des developpeurs 
en partie a cause des liens privilegies du langage C avec les standards Posix et les sys- 
temes de type Unix. Historiquement, le langage C est egalement un langage permettant 
une programmation relativement proche du materiel, done bien adaptee au logiciel 
embarque. 

La contrainte principale etant le plus souvent l'empreinte memoire, la programmation en 
langage C necessite d'utiliser le compilateur de la maniere la plus efficace possible, et ce 
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en utilisant au maximum les options d'optimisation adaptees au materiel. Dans le cas du 
compilateur GNU gcc (GNU C Compiler), on notera en particulier les options suivantes 
-03, -02, -03, selon le niveau d'optimisation, et -0s qui permet d'optimiser le code afin 
de minimiser sa taille. Des options specifiques au processeur utilise comme -m386 ou 
-mpenti urn permettront egalement d'adapter le code au materiel utilise. 

Dans le cas de l'utilisation de systemes de type Unix (on dit aussi UNIX-like), on pourra 
egalement employer d'autres langages de programmation ou langages de scripts plus 
appropries dans certains cas. On citera en particulier le shell-script, langage de script 
d'Unix (ou Bourne shell, du nom de son concepteur Steve Bourne), qui associe a d'autres 
commandes pourra se reveler tres utile dans l'ecriture de procedures systeme. Le resultat 
sera le plus sou vent plus facile a maintenir qu'un programme ecrit en langage C et sur- 
tout ne necessitera pas de recompilation avant execution sur un autre systeme de type 
Unix. Des versions tres fonctionnelles du Bourne-shell comme ash ou msh n'occupent 
respectivement pas plus d'une soixantaine et une trentaine de kilo-octets, ce qui est tres 
admissible dans la majorite des systemes. D'autres produits encore plus reduits, comme 
BusyBox que nous decrirons dans la deuxieme partie, permettent d'integrer des versions 
simplifiees d'un bon nombre de commandes Unix dans seulement 150 kilo-octets. 

D'autres langages de scripts celebres dans le monde Unix comme Perl, Tcl/Tk ou Python 
sont eux assez peu utilises dans les environnements embarques de par l'espace memoire 
necessaire a leur installation et a leur fonctionnement. 



Tour d'horizon des systemes existants 

Nous allons terminer ce chapitre en effectuant un rapide tour d'horizon des principaux 
systemes d' exploitation utilises dans les environnements embarques. Ce tour d'horizon 
n'inclut pas les systemes a base de Linux qui seront decrits dans le chapitre suivant. 



Remarque 

II est difficile de recenser les nombreux systemes embarques existants d'autant que certains industriels ont 
parfois developpe leurs propres systemes afin de satisfaire a des besoins ou des normes tres particulieres (cas 
de I'aeronautique). 



VxWorks et pSOS 

A tout seigneur tout honneur, VxWorks est aujourd'hui le noyau temps reel le plus utilise 
dans l'industrie. II est developpe par la societe Wind River (http://www.windriver.com) qui 
a egalement rachete recemment les droits du noyau temps reel pSOS, un peu ancien, mais 
egalement largement utilise. VxWorks inclut en natif un support TCP/IP et une interface 
de programmation integrant les sockets. Le gros inconvenient de ces deux systemes est le 
cout important des licences. II est egalement necessaire d'utiliser un environnement de 
compilation croise. 
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Rappel 

Un environnement de compilation croise permet de developper pour le systeme cible sur une autre machine 
dans un environnement plus confortable. On peut citer par exemple la disponibilite sous Linux d'un environne- 
ment de developpement pour PalmOS, base sur le compilateur GNU gcc. 

QNX 

Developpe par la societe canadienne QNX Software (http://www.qnx.com), QNX est un 
noyau temps reel de type Unix tres interessant. II est parfaitement conforme a Posix, per- 
met de developper directement sur la plate-forme cible et integre 1' environnement gra- 
phique Photon, proche de X Window System. Conscient de la percee de Linux dans le 
monde de l'embarque, QNX Software s'en est rapproche en mettant a disposition la 
majorite des outils GNU sur la plate -forme QNX. Autre avantage non negligeable : QNX 
peut etre utilise gratuitement pour des applications non commerciales. 

II peut occuper une tres faible empreinte memoire et, de ce fait, peut etre utilise dans des 
environnements tres reduits comme les telephones portables GSM Timeport de chez 
Motorola. 

|iC/OS (micro-C OS) et |iC/OS II 

uC/OS, developpe par le Canadien Jean J. Labrosse, est destine a des environnements de 
tres petite taille comme des micro-controleurs de type Motorola 68HC11. II est mainte- 
nant disponible sur un grand nombre de processeurs et peut integrer des protocoles stan- 
dards comme TCP/IP (uC/IP). II est utilisable gratuitement pour l'enseignement et de 
nombreuses informations sont disponibles sur http://www.ucos-ii.com. 

Windows CE 

Annonce avec fracas par Microsoft comme le systeme d' exploitation embarque qui tue, 
Windows CE et ses cousins comme Embedded Windows NT n'ont pour l'instant pas 
detrone les systemes embarques traditionnels. Victime d'une reputation de fiabilite 
approximative, Windows CE est pour l'instant cantonne a l'equipement de nombreux 
assistants personnels (PDA, Personal Digital Assistant). Des informations sont disponi- 
bles sur http://www.microsoft.com/windows/embedded. 

LynxOS 

LynxOS est developpe par la societe LynuxWorks (http://www.lynuxworks.com) qui a 
recemment modifie son nom en raison de son virage vers Linux avec le developpement 
de BlueCat. C'est un systeme temps reel conforme a la norme Posix. 

Nucleus 

Nucleus est developpe par la societe Accelerated Technology Inc. (http://www.accelerated- 
technology.com). C'est un noyau temps reel qui inclut une couche TCP/IP, une interface 
graphique (Graphix) ainsi qu'un navigateur web (WebBrowse) et un serveur HTTP (Web- 
Serv). II est livre avec les sources et il n'y pas de royalties a payer pour la redistribution. 
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eCos 

Acronyme pour Embeddable Configurable Operating System, eCos fut initialement 
developpe par la societe Cygnus, figure emblematique et precurseur de l'Open Source 
professionnel, acquise ensuite par la societe Red Hat Software. C'est un systeme d' exploi- 
tation temps reel bien adapte aux solutions a tres faible empreinte memoire et profondement 
enfouies. Son environnement de developpement est base sur Linux et la chaine de compi- 
lation GNU avec conformite au standard Posix et disponibilite de protocoles standards 
comme TCP/IP. Argument non negligeable, il est diffuse sous une licence proche de la GNU 
GPL {General Public licence) et disponible en sources sur http://ecos.sourceware.org. 
La societe eCosCentric fondee en 2002 par les responsables du projet eCos chez Red Hat 
fournit des versions professionnelles et du support ( voir http://www.ecoscentric.com). 

Le systeme eCos est largement utilise dans l'industrie automobile, dans certaines impri- 
mantes laser ou bien des produits multimedias comme le lecteur MP3 HitZip de chez 
Iomega. II est disponible pour un grand nombre de processeurs comme les x86, 
PowerPC, ou SH3 Hitachi ou StrongARM. 

En resume 

Les logiciels et systemes embarques sont toujours dedies a un equipement. 

Un equipement dedie a une tache donnee est appele appliance ou serveur d' application. 

Les systemes classiques utilisent le principe du temps partage. Sa priorite est le confort 
de l'utilisateur. Un systeme temps reel doit en revanche respecter les contraintes tempo- 
relies, et ce quelle que soit sa charge. Son comportement doit etre previsible. La version 
standard du noyau Linux n'est pas temps reel. 

Lempreinte memoire d'un systeme embarque peut varier de 64 Mo a 0,1 Mo. On parle 
alors de systeme profondement enfoui. 

Les langages les plus repandus dans le monde de 1' embarque sont le C, le C++ et 
l'assembleur. 

II existe une multitude de systemes d' exploitation a embarquer. Plusieurs declinaisons de 
Linux existent d'ores et deja pour les applications embarquees ; elles seront citees au 
chapitre suivant. 
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Linux comme systeme embarque 



Le chapitre precedent a decrit quelles etaient les caracteristiques d'un systeme embarque, 
les differents types de systemes ainsi que leurs applications. Le present chapitre va s'atta- 
cher a detailler les nombreux avantages - mais aussi les quelques contraintes - inherentes 
au choix de Linux comme systeme embarque. 

Contraintes des systemes embarques proprietaires 

Le monde des systemes embarques est encore domine par les editeurs de solutions pro- 
prietaires comme le demontre la figure ci-apres, qui donne la repartition des systemes 
utilises a la fin du xx e siecle : 



Quel systeme temps reel avez-vous utilise pour vos 
applications embarquees ces 12 derniers mois ? 
Tendances d'utilisation des systemes, 1998-2000 

(les choix multiples sontpemris. En 2000, setd letop 6 est indique) 



D1998 




11999 



□ 2000 



n rj rti 



Vx Works bmbedded 
Windows 



iisijt; 



Embedded Nucleus VK1X 
Linux 



(Source: Etude des alonnes a Emledded Systems frogranmiing Magazine en 2000) 



Figure 2-1 

Repartition des systemes 
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Ces systemes, pour la majorite, souffrent cependant de quelques defauts forts contrai- 
gnants pour les concepteurs d'equipement. 

lis sont souvent realises par des societes de taille moyenne qui ont du mal a suivre revo- 
lution technologique : le materiel evolue tres vite - la duree de vie d'un processeur est de 
l'ordre de 12 a 24 mois ; il en est de me me des standards logiciels et de plus en plus 
d'equipements necessitent l'integration de composants que Ton doit importer du monde 
des systemes informatiques classiques ou du multimedia. 

De ce fait, les couts de licence et les droits de redistribution des systemes sont parfois tres 
eleves car l'editeur travaille sur un segment de marche tres specialise, une niche dans 
laquelle les produits commercialises le sont pour leur fonction finale et non pour la valeur 
du logiciel lui-meme. Contrairement au monde de la bureautique ou la pression commer- 
ciale peut inciter l'utilisateur a faire evoluer son logiciel frequemment - et done a payer 
un complement de licence -, le logiciel embarque est considere comme un mal neces- 
saire, souvent destine a durer plusieurs annees, en conservant une compatibilite avec du 
materiel et des processeurs obsoletes. 

Concernant ce dernier point, 1'industriel qui utilise un systeme proprietaire prend le ris- 
que de voir disparaitre l'editeur ou meme le systeme ainsi que le support technique qui va 
avec. Pour eviter au maximum ce genre de situation dramatique, les industriels paient 
souvent des sommes consequentes afin de disposer de tout ou partie des sources du sys- 
teme. Si tel n'est pas le cas, ils devront utiliser des methodes hasardeuses comme le 
reverse engineering (ingenierie inverse ou « retrotechnique ») qui consiste a tenter de 
comprendre le fonctionnement du logiciel sans disposer des sources, et ce en effectuant 
un « desassemblage » des programmes. 

Le cofit de developpement d' applications autour de systemes proprietaires est souvent 
plus eleve car les outils de developpement disponibles sur le marche du travail sont mal 
connus de la majorite des developpeurs car non etudies a l'universite. II est done neces- 
saire de recruter du personnel tres specialise done rare... et cher. Les formations, tres 
« pointues », autour de ces outils sont egalement onereuses, ce qui oblige l'editeur a pra- 
tiquer des couts eleves pour compenser le manque d'effet de masse. Tout cela implique un 
ensemble de specificites contraignantes pour la gestion globale des outils informatiques 
de l'entreprise. 



Les avantages de I'Open Source 

Le concept d'Open Source a ete introduit dans l'avant-propos. Les trois points suivants 
de la definition du logiciel Open Source sont fondamentaux dans le cas du logiciel embar- 
que : 

• redistribution sans royalties ; 

• disponibilite du code source ; 

• possibilite de realiser un developpement derive de ce code source. 
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Le premier point regie le probleme economique des droits de redistribution ou royalties, 
tres contraignant dans le cas d'un systeme distribue a grande echelle. La disponibilite du 
code source est encore plus fondamentale car elle est la base de la conception d'un logi- 
ciel de qualite et surtout maintenable dans le temps. 

Si un bogue est detecte dans le systeme sur lequel sont developpees les applications, la 
disponibilite du code source permettra a coup sur de corriger le probleme, a supposer que 
Ton dispose de la competence adequate. Sur ce point, le fait d'utiliser des logiciels large- 
ment repandus comme Linux augmente les chances de pouvoir trouver assez facilement 
cette competence. 

Si le systeme doit « vivre » plusieurs annees, il sera toujours possible grace a l'Open 
Source d'en realiser une image complete ainsi que de tous les outils de developpement 
associes, de maniere a pouvoir generer a tout moment un nouveau systeme cible sur une 
plate -forme compatible. Ce critere de perennite est extremement important dans un pro- 
cessus industriel. 

La disponibilite du code source facilite la comprehension du systeme et done augmente 
la qualite et la stabilite des applications developpees pour ce dernier. La documentation 
des logiciels Open Source largement repandus comme Linux est souvent de tres bonne 
qualite car elle a pu beneficier d'un gros travail collaboratif. Meme si - tradition et statis- 
tique obligent - elle est souvent plus a jour en langue anglaise, la diffusion publique de 
1' information permet egalement de disposer de versions internationales. Le projet LDP 
(Linux Documentation Project) disponible a partir du site http://www.linuxdoc.org en est 
un excellent exemple. 

Le dernier point concernant la facilite de comprehension est verifie quel que soit le type 
de developpement logiciel, et ce independamment du cote Open Source. L' exemple le 
plus frappant est le navigateur Internet Explorer de Microsoft. Sans etre un grand admi- 
rateur de Microsoft, il faut admettre que leur navigateur, developpe par des equipes ayant 
une connaissance intime de Windows, est aujourd'hui plus performant que son rival 
Netscape Communicator. Cela ne signifie pas forcement que les developpeurs de Micro- 
soft sont meilleurs que ceux de Netscape, mais plutot que la disponibilite des sources est 
un atout majeur pour la qualite des developpements. 

Meme s'il est excessif d'affirmer qu'un logiciel Open Source est toujours de meilleure 
qualite qu'un logiciel « ferme », il est important de noter que le fait de diffuser les sources 
oblige le developpeur a soigner ce code car il va ainsi etre juge par ses pairs. Tout vrai 
developpeur de logiciel a un cote artiste et creatif qui provoque chez lui un sentiment 
d' excitation et de fierte lorsqu'un affichage graphique est plus harmonieux ou un algo- 
rithme de calcul plus optimise. La notion d'Open Source est done une bonne garantie de 
qualite, sans oublier que la publication des sources facilite d'autant 1' amelioration rapide 
du code qui sera visible par des milliers d'autres programmeurs. 

II est fondamental de faire la difference entre le logiciel gratuit (freeware) et le logiciel 
Open Source communement appele logiciel litre en francais, bien que la traduction de 
free par gratuit conduise souvent a des confusions. II existe de nombreux logiciels gra- 
tuits disponibles sur Internet dont les sources ne sont pas disponibles. II peut aussi arriver 
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que les sources d'un logiciel gratuit soient disponibles pendant un certain temps mais les 
licences de ces logiciels, souvent peu precises, ne garantissent pas en general leur dispo- 
nibilite, ce qui est un risque majeur dans un processus industriel. 

La plupart des logiciels Open Source sont eux regis par des licences tres structurees dont 
la plus celebre est la GPL (General Public Licence), explicitee dans l'avant-propos. Cette 
licence est statistiquement la plus utilisee dans l'environnement Linux car elle permet de 
garantir le mieux possible la disponibilite permanente des sources d'un logiciel libre. 

Contrairement a certaines legendes, l'utilisation de la GPL ou de la LGPL (Lesser GPL) 
est parfaitement compatible avec l'approche industrielle. Si tel n'etait pas le cas, il ne 
serait pas possible de diffuser des versions Linux d' applications commerciales autres 
qu'Open Source. La LGPL permet la diffusion de code proprietaire - done sans les sour- 
ces - lie a des bibliotheques GPL comme la glibc (GNU libc). Meme si cette possibility 
ne satisfait pas les « jusqu'au-boutistes » du logiciel libre, elle a l'avantage d'avoir permis 
1' introduction progressive de Linux dans l'industrie, chose qui n'aurait pas ete possible si 
Ton avait propose aux industriels de remplacer leurs applications favorites par des equi- 
valents, certes Open Source, mais a l'epoque parfaitement inconnus du monde industriel. 

La GPL n'est cependant pas la seule licence communement utilisee dans le monde du 
logiciel libre car elle est parfois consideree par certains comme trop contraignante. Les 
licences BSD (Berkeley Software Distribution) et MIT (Massachusetts Institute of Techno- 
logy) sont egalement largement utilisees, en particulier pour l'interface graphique 
X Window System qui utilise la licence MIT. La difference principale avec la GPL est la 
non-obligation de rediffusion systematique (ou copyleft) des sources des applications 
derivees de sources sous licence BSD ou MIT. Lenonce des licences BSD et MIT est 
egalement beaucoup plus simple, quelques lignes au lieu de plusieurs pages pour la GPL 
et la LGPL. 



The MIT licence 

Copyright (c) <year> <copyright holders> 

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated 
documentation files (the "Software"), to deal in the Software without restriction, including without limitation the 
rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to 
permit persons to whom the Software is furnished to do so, subject to the following conditions: 

The above copyright notice and this permission notice shall be included in copies or substantial portions of the 
Software. 

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, 
INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICU- 
LAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT 
HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF 
CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFT- 
WARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. 
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La liste des principales licences Open Source est disponible sur le site http://www.open- 
source. org/licenses. 



Et les quelques contraintes... 

L'utilisation de Linux et des logiciels libres peut cependant entrainer quelques contraintes 
dans un environnement industriel. En premier lieu, se pose le probleme de la credibilite 
de l'Open Source par rapport aux editeurs de logiciels classiques. Le probleme ne vient pas 
des ingenieurs qui sont la plupart du temps les premiers a valider la superiorite technique 
des solutions Open Source. L'Open Source a plutot une approche communautaire qui 
peut provoquer la mefiance des decideurs pour lesquels ce mot a une connotation anti- 
liberale, et peut etre interprets comme anti-profit. L'ingenieur ou l'equipe technique qui 
choisira un logiciel libre par rapport a une solution proprietaire pourra etre en opposition 
avec sa hierarchie, ce qui est rarement agreable. On ne licenciera jamais un directeur infor- 
matique pour avoir fait le choix d'un produit commercial qui a pignon sur rue, me me si le 
logiciel connait des problemes d' installation ou de fonctionnement. Le choix d'une solu- 
tion Open Source peut etre beaucoup plus risque politiquement car a la premiere diffi- 
culty les detracteurs ne manqueront pas de ricaner en disant : « C'est gratuit done 5a n'est pas 
fiable. ». 

La rumeur et la meconnaissance des licences sont bien entendu entretenues par les edi- 
teurs pour lesquels l'Open Source constitue une menace. Certains membres de la presse 
specialised, pour lesquels les editeurs de solutions proprietaries constituent la principale 
clientele d'annonceurs, furent dans le passe souvent peu enclins a demontrer la superio- 
rite des solutions Open Source. La logique est economique : un gros editeur pourra payer 
des specialistes du marketing et des relations de presse, la meme approche ne pourra pas 
etre possible pour un projet Open Source. 

En second lieu, se pose le probleme important du support technique qui est fortement 
ancre dans les esprits. Par essence, le logiciel libre est livre en I'etat (as is) et ce sans 
aucune garantie de bon fonctionnement. Si l'utilisateur desire de l'assistance, il devra uti- 
liser les canaux traditionnels des documentations et FAQ - Frequently Asked Questions, 
parfois traduit en francais par Foire aux questions - disponibles sur Internet, des groupes 
de discussion (newsgroups) ou le cas echeant des courriers electroniques echanges direc- 
tement avec les auteurs. Ces methodes sont techniquement tres efficaces car un probleme 
frequent sur un logiciel libre est forcement reference quelque part sur Internet. Durant ma 
longue experience du logiciel libre, je ne peux pas citer un seul probleme que je n'ai pas 
pu resoudre via la source directe qu'est Internet. Cette logique est cependant une approche 
d'ingenieur et celle d'un juriste ou d'un chef d'entreprise sera differente car ces derniers 
chercheront plutot une responsabilite legale au probleme meme si cela ne le corrige pas ! 

Le point crucial du support est la pierre angulaire du modele economique des societes 
gravitant autour du logiciel libre. Puisqu'elles ne peuvent faire de profit sur la vente de 
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licence, le profit sera realise sur le support associe au produit. Les gros editeurs de distribution 
Linux comme Red Hat ou Mandriva (ex-Mandrake) suivent ce modele : la distribution 
est disponible sur Internet ou bien sur des CD-Rom gratuits qui contiennent les memes 
paquetages logiciels qu'une version payante mais sur lesquels l'editeur ne delivrera aucun 
support technique, ni documentation « papier ». La valeur ajoutee de la version payante 
se fera sur la presentation du produit et le support ou service associe. 

D'autres societes sont exclusivement axees sur le support technique et le service, sans 
etre editrices de logiciel. Cette approche apporte une plus grande souplesse dans le choix 
des composants Open Source car cela permet de puiser les composants dans diverses dis- 
tributions, voire dans des projets non edites. Cette demarche est plus difficile pour un edi- 
teur de distribution qui aura la contrainte d'utiliser exclusivement ses produits, du moins 
dans certains domaines. Meme si l'existence de ces societes est un grand pas en avant, 
leur jeunesse et leur assise financiere parfois precaire peuvent gener les industriels. A la 
difference des solutions proprietaires, une solution Open Source n'est cependant jamais 
definitivement perdue meme si la societe qui la supporte n'existe plus. La disponibilite 
des sources est la meilleure garantie de perennite. 

Enfin, parmi les contraintes existantes, il faut mentionner la complexite et la multiplicite 
des licences Open Source. Celles-ci sont en nombre relativement important - plus de 
vingt licences courantes repertoriees sur http://www.opensource.org - et leur approche 
peut etre deroutante pour les juristes habitues aux licences classiques. La licence GPL 
s'etale sur 17 pages et il faut etre un peu initie afin d'en saisir toutes les subtilites. 

Dans le cas des systemes embarques, l'exemple classique de contrainte inherente a la 
GPL est l'impossibilite de mixer le code GPL original du noyau Linux avec du code pro- 
prietaire. Si vous developpez un pilote de peripherique a partir du source d'un pilote exis- 
tant (done sous GPL), la licence vous oblige a diffuser le source du pilote. Meme si vous 
ecrivez entierement un pilote de peripherique, la licence GPL vous oblige a diffuser son 
source si vous desirez le lier statiquement au noyau original sous GPL. La solution ele- 
gante consiste done a utiliser systematiquement les pilotes sous formes de modules dyna- 
miques non lies a la partie statique du noyau. Cette technique est decrite dans le 
chapitre 4. 

Dans le cas de diffusion d' applications proprietaires sous Linux, la LGPL {Lesser GPL) 
permet de diffuser une application utilisant des composants sous LGPL, comme la glibc 
(GNU libc, bibliotheque principale utilisee par tous les applicatifs Linux). L extension 
de la GPL a la LGPL fut la condition sine qua non pour la disponibilite d' applications 
commerciales classiques sur la plate -forme Linux. 

Une derniere contrainte concerne les problemes de compatibilite ascendante. Pour des 
raisons commerciales, les editeurs sont le plus souvent tenus de respecter la compatibilite 
de leur version courante avec des versions tres anciennes. Le cas le plus celebre est la 
compatibilite des systemes Microsoft Windows avec Fancien systeme MS-DOS, conservee 
jusqu'a la version Windows 98. Les developpeurs de projets Open Source n'ont pas cette 
contrainte et la compatibilite ascendante du produit n'est pas garantie. II faut cependant 
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ajouter un bemol a ce dernier point. La disponibilite des sources completes du systeme 
permet a tout moment de travailler sur un produit, meme tres ancien, et d'y ajouter certains 
composants actuels en effectuant un portage « retro-actif » (backport), d'autant que Linux 
est souvent beaucoup mieux structure que d'autres systemes. 

Pourquoi Linux est-il adapte a lembarque ? 

Si les systemes proprietaries dominent encore le marche de l'embarque en ce debut de 
xxi e siecle, une etude de marche realisee en 2000 par VDC (Venture Development Cor- 
poration) prevoit un marche Linux embarque de 305 millions de dollars en 2005 contre 
seulement 28 millions en 2000 et 55 millions en 2001. De meme, si 59 % des industriels 
afhrment debut 2001 ri avoir jamais utilise Linux pour une application embarque, 19 % 
repondent 1' avoir utilise sur un projet et 22 % afhrment 1' avoir utilise sur de multiples 
projets (source CNET Networks Inc.). 

Le graphique ci-apres indique la repartition de 1' utilisation de Linux sur des delais de 
projets variant de zero (projets actuels) a deux ans. La encore, 47 % des industriels inter- 
roges afhrment avoir actuellement un ou plusieurs projets utilisant Linux comme systeme 
embarque (source CNET Networks Inc.). 

Remarque 

Suite a I'etude Embedded Linux Market Survey realisee par LinuxDevices.com, en 2003/2004, des statistiques 
plus recentes sont disponibles a I'adresse http://www.linuxdevices.com/news. Nous vous encourageons done 
a consulter les dernieres versions en ligne. 

Figure 2-2 

Repartition des projets Quand pensez-vous demarrer votre premier projet 

sous LINUX embarque ? 

Pas decide 
16% 

D'ici 1 a 2 ans 
Bit 

D'ici6al2mois ' Deja en corns 

13% 47% 



D'ici 116 mois 
18% 



Dernier element, parmi les 58 % des industriels qui ont choisi Linux, 20 % declarent que 
e'est en raison de la disponibilite des sources, 19 % pour le cout et 18 % pour la habilite. 
Le graphe presente ci-apres donne la repartition complete des motivations. 




Systemes embarques, generalites 

Premiere partie 



Pourquoi envisagez-vous LINUX 


pour une application 


embarquee ? 








Developpeuis faciles 
a ttouver 


, Ne 


vi&ntpas de Microsoft Code source libra 


i% 




9% 


r et disp orrible 


Pilotes &t utOitaic&s 




V^ 


20% 


disponibl&s 

8% 


V 






^^J, Pas de royalties 








jr ia% 


Tres bon support 








r&seau 








16% 






jt Rotraste et fiable 

ie% 

(Cwn 02CB1 , C^T Hit^tii, i"i J 



Figure 2-3 

Repartition des motivations 



Fiabilite 



Linux est repute pour sa fiabilite et Ton peut affirmer que cette reputation n'est pas usur- 
pee. En dix ans d'utilisation de Linux, je peux compter sur les doigts de la main les cas 
de « plantage » inexpliques. Le fameux kernel panic (erreur fatale du noyau) tant redoute 
par les developpeurs est un animal rare, presque autant que le Yeti ou le monstre du Loch 
Ness. Une erreur de ce type s'explique toujours par un probleme materiel ou une erreur 
de programmation dans un pilote de peripherique. Ces derniers travaillant dans un espace 
privilegie appele « espace noyau » {kernel space ou kernel level), ils sont les seuls a pou- 
voir provoquer ce type d' erreur. Les autres applications travaillent dans 1' espace dit utili- 
sateur {user space ou user level) et n'ont pas les droits necessaires a la generation de ce 
type d' erreur. 



Attention 

Linux dispose cependant de fonctions speciales (comme lopl ou ioperm) permettant a un programme de 
I'espace utilisateur de s'approprier des droits d'acces a des ressources normalement reservees au noyau 
et susceptibles de generer des plantages du systeme. Lutilisation de ces fonctions doit etre reservee a 
des cas extremes ou des situations temporaires et il est toujours plus prudent de developper un pilote de 
peripherique. Notez que ces fonctions ne sont par portables vers d'autres systemes. 



La fiabilite de Linux est demontrable au moyen de la commande uptime qui permet 
d'afficher le temps d'activite du systeme depuis le dernier redemarrage. La valeur du 
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temps d'activite donne lieu a des concours, et des valeurs de plusieurs mois sont monnaie 
courante. La couche TCP/IP de Linux, au coeur de nombreuses applications embarquees 
communicantes, est egalement d'une grande fiabilite. 



Faible cout 



La contrainte economique est bien evidemment tres importante dans le cas du developpe- 
ment d'un systeme embarque. Linux est non seulement exempt de royalties mais les 
outils de developpement sont egalement disponibles sous GPL. Le seul effort financier 
necessaire a l'adoption de Linux se situe sur la formation - souvent indispensable - et le 
support technique. 

La periode difficile ayant suivi l'engouement pour la nouvelle economie peut etre de ce 
fait une chance pour Linux car il est beaucoup moins couteux de realiser une etude avec 
Linux qu'avec un autre systeme fonctionnant sur une base de royalties. 



Attention 

Nous ne saurions trap mettre en garde le lecteur contra la tentation du « tout gratuit » sous Linux. Le fait de 
recourir a des prestations externes pour la formation et I'assistance au developpement d'un projet Linux embar- 
que peut faire gagner un temps precieux et permettre un transfert technologique efficace en vue des projets 
suivants. Plus generalement, cette approche du « tout gratuit » peut mettre en peril I'industrie du logiciel libra 
exclusivement basee sur le service et le support. Le fait de profiter des enormes avantages de I'Open Source 
implique une certaine deontologie qui se revele etre un avantage a moyen et long terme. Les statistiques 
semblent rassurantes sur ce point puisque 68 % des utilisateurs sont disposes a payer un support technique 
contra 13 % qui n'y sont pas disposes et 19 % qui sont indecis (source CNET Networks Inc.). 



Performances 

Les performances de Linux ne sont plus a prouver. De nombreux tests comparatifs (ben- 
chmarks) entre Linux et d' autres systemes concurrents comme Windows NT on demon- 
tre la superiorite de Linux. Des resultats de tests sont disponibles en particulier sur le site 
du Linux Test Project (http://ltp.sourceforge.net). Cependant, les benchmarks ne sont pas 
forcement le meilleur critere car ils sont souvent realises dans des conditions particulie- 
res, parfois eloignees des situations reelles. Pour se rendre compte des capacites de 
Linux, le mieux est encore de le tester soi-meme. Detail interessant pour les applications 
embarquees, c'est dans des situations de faibles performances materielles que Linux se 
revele le plus efficace par comparaison a d' autres systemes. 

Portability et adaptability 

La portability est egalement un des points forts de Linux. Meme si le premier courrier de 
Linus Torvalds en 1991 annoncait clairement que Linux ne tournerait jamais sur autre 
chose que les processeurs x86, le fait est qu'il s'est pour une fois lourdement trompe. 
Linux est aujourd'hui porte sur un tres grand nombre de processeurs et d' architectures 



Systemes embarques, generalites 

Premiere partie 

materielles, y compris des processeurs de faible puissance, comme le demontre le projet 
uClinux (http://www.uclinux.org). Meme si le processeur ou l'architecture que vous desirez 
utiliser ne figured pas dans la liste des portages actuels, l'enorme base de connaissance 
disponible facilitera le travail et vous pourrez sou vent vous inspirer de travaux deja reali- 
ses. De meme, sachant que Linux est de plus en plus introduit dans les universites et 
organismes d'education en tout genre, les competences seront beaucoup plus faciles a 
trouver que sur d'autres systemes a la reputation plus confidentielle. 

La structure modulaire de Linux heritee de l'architecture Unix est egalement un de ses 
gros avantages. La structure du systeme est stride et clairement definie, et il sera aise de 
le configurer de maniere a trouver une correspondance exacte avec les besoins dans les 
limites des contraintes materielles, quitte a ajouter des composants plus tard. Si on sou- 
haite par exemple ajouter le support d'un protocole reseau comme PPP (Point to Point 
Protocol), il suffira d' ajouter au systeme le module noyau du support PPP ainsi que le 
client de connexion, ces derniers etant valides depuis longtemps sur les versions completes 
du systeme. II ne faut jamais oublier que les developpements Linux ne sont pas limites a 
ceux d'un systeme embarque, ce qui est un gros avantage, tant en termes de rapidite de 
disponibilite des composants que pour ce qui est de leur qualite. 

Ouverture 

De par sa conception Open Source, Linux est ouvert. Ce concept d' ouverture se situe a 
deux niveaux. 

Le premier niveau concerne l'interoperabilite de Linux avec d'autres systemes d'exploi- 
tation. Certains systemes comme les differentes versions de Windows ont une approche 
hegemonique de l'informatique, c'est-a-dire qu'ils considered par defaut qu'ils sont les 
seuls acteurs d'une configuration informatique complete. C'est bien entendu absurde 
et l'utilisateur en fait les frais ; nous citerons par exemple la procedure d' installation 
Windows 9x qui detruira invariablement le secteur de demarrage (boot sector) du disque 
meme si un autre systeme comme Linux est deja installe. II y a pire, par exemple lorsque 
la meme procedure d' installation peut s'allouer autoritairement tout le volume du disque 
si l'utilisateur n'a pas pris la precaution d'estampiller la premiere partition comme etant 
de type FAT32 qui est un des formats de systeme de fichier de Windows. 

Au contraire, Linux a une approche collaborative, ce qui signifie qu'il va s'integrer dans 
un environnement existant de maniere a optimiser les performances globales du systeme 
informatique et done faciliter la vie de l'utilisateur. Les exemples en sont nombreux et on 
peut en citer quelques-uns : 

• Linux permet depuis le debut de lire et ecrire les donnees presentes sur une partition 
Windows (FAT ou FAT32). Le contraire n'est possible qu'apres installation de logi- 
ciels tiers. 

• Linux peut s'installer sur n'importe quelle partition de n'importe quel disque du sys- 
teme. Cela n'est pas possible pour certaines versions grand public de Windows qui ne 
fonctionnent qu'a partir de la premiere partition du premier disque. 
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• Linux inclut des programmes de demarrage comme LILO ou GRUB qui permettent de 
demarrer alternativement sur l'un des systemes presents sur la machine. Cela n'est 
possible que sur certaines versions de Windows. 

• Linux supporte depuis le debut le protocole reseau de Windows appele SMB ou CIFS. 
II suffit pour cela d'installer le logiciel Open Source SAMBA (http://www.samba.org) 
livre avec Linux. Le support du protocole NFS, equivalent Unix de SMB, n'est dispo- 
nible qu'en ajoutant a Windows un logiciel tiers. 

Le second niveau d'ouverture concerne l'adoption dans Linux des nouvelles technolo- 
gies, pour peu que celles-ci constituent des standards ouverts. Le fait que Linux soit tota- 
lement Open Source facilite 1' adaptation et le test de nouveaux protocoles car tous les 
secrets du systeme sont a portee de main, du moins si Ton sait ou les chercher. La plate- 
forme Linux constitue done un choix avantageux pour les developpeurs et les scientifiques 
d'autant que les experiences de developpement sont le plus souvent partagees sur Internet. 
Nous citerons a ce titre les plates-formes collaboratives SourceForge (http://www.source- 
forge.net) qui heberge a ce jour environ 30 000 projets Open Source et le plus recent 
GNU Savannah (http://savannah.gnu.org) qui en heberge « seulement » 400. 



Dans quels cas Linux peut-il etre inadapte ? 



II peut exister des cas dans lesquels Linux sera inadapte. Si le systeme a embarquer 
necessite uniquement des fonctions de base n'incluant pas de support reseau ni de multi- 
tache et si cet equipement n'est pas destine a evoluer, il n'est pas forcement interessant 
d'utiliser un systeme aussi riche que Linux. En effet, un noyau Linux occupera au mini- 
mum 400 kilo-octets en version compressee et il sera difficile de tomber en dessous du 
mega-octet pour un systeme minimal fonctionnel. Concernant la memoire vive, il ne faut 
pas esperer faire fonctionner correctement le noyau standard dans moins de 4 mega- 
octets. 

Si vos contraintes materielles ne sont pas compatibles, oubliez Linux et rabattez-vous sur 
d'autres systemes comme eCos ou uC/OS cites dans le chapitre precedent, ou au pire sur 
un logiciel dedie developpe par vos soins. Soyez cependant attentif a ne pas developper 
le systeme a trap court terme ; un systeme Linux est tres evolutif et pourra suivre les 
evolutions technologiques de votre produit pendant longtemps. L'ajout d'un nouveau 
protocole a un systeme « maison » est souvent une tache longue et difficile. 

L utilisation de la GPL/LGPL peut egalement se reveler contraignante ou bien heurter 
la sensibilite de votre hierarchie ou la votre. Dans ce cas, il se peut que vous soyez con- 
traints d'utiliser une solution proprietaire ou bien une autre solution Open Source basee 
sur un autre type de licence, par exemple la licence BSD. Des industriels utilisent 
FreeBSD (http://www.freebsd.org) comme systeme embarque entre autres pour des raisons 
de facherie avec la GPL. FreeBSD est un excellent systeme, au moins aussi performant 
que Linux, mais qui dispose d'une moins grande notoriete en depit de son plus grand age. 
Mefiez-vous cependant de contraintes liees a la disponibilite des pilotes de peripheriques 
ou alors armez-vous de patience et de bons collaborateurs ! 
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La conformite par rapport a certains standards industriels (comme les standards de 
l'aeronautique) peut etre difficile a valider. La question n'est pas technique mais, du fait 
de la diversite des sources d'information et de diffusion des composants Linux, il existe 
rarement une societe unique qui puisse decider de financer une etude de conformite. Si la 
conformite interesse un faible nombre d' applications, les modifications necessaires 
auront peu de chances d'etre integrees a 1' arborescence officielle et si ces modifications 
sont finalement realisees par une societe ou un groupe d'individus, il y aura perte de 
compatibility des sources par rapport a la version officielle du noyau. 

Independamment des applications embarquees, la multiplication des sources d'informa- 
tions et des standards, qui de ce fait n'en sont pas, est a la fois un avantage et un inconve- 
nient de Linux. II n'y a pas de voix unique, il existe toujours des partisans de GNOME, 
de KDE, ou d'autres bureaux graphiques moins connus, done des utilisateurs de GTK et 
de Qt, les bibliotheques a la base de ces deux bureaux. II s'ensuit une grande liberte mais 
aussi un sentiment de cafouillage pour les non-inities - un peu a 1' image du « bazar » qui 
se tient face a la cathedrale, interessant mais parfois difficile a integrer. 

Les systemes embarques bases sur Linux 

II existe d'ores et deja un grand nombre de distributions et composants embarques bases 
sur Linux dont la majorite est constitute de projets Open Source. 

MontaVista Linux 

Developpe par la societe Monta Vista (http://www.mvista.com), MontaVista Linux est le 
leader des solutions Linux embarque commerciales. MontaVista est a l'origine des modi- 
fications du noyau Linux afin d'ameliorer la preemption de ce dernier et done les fonction- 
nalites de temps reel « mou ». De nos jours, MontaVista met plutot en avant la liste tres 
fournie des processeurs supportes par ses outils de compilation (voir http://www.mvista.com). 

BlueCat Linux 

Ce produit est edite par Lynux Works, createur et editeur du systeme temps reel LynxOS. 
La nouvelle version BlueCat Linux 5.0 est basee sur le noyau 2.6 et profite done de la 
fonction de noyau preemptif de ce dernier. LynuxWorks annonce egalement que les exe- 
cutables developpes sous BlueCat sont compatibles binaires avec leur systeme temps reel 
dur proprietaire LynxOS (voir http://www.lynuxworks.com/products/bluecat/bluecat.php3). 



jjdinux 



uClinux est un portage du noyau Linux pour micro-controleurs et processeurs depourvus 
de MMU (Memory Management Unit). De ce fait, il n'y a pas de protection memoire 
d'un programme a 1' autre et un programme peut planter un autre programme ou le noyau 
lui-meme. Tres ouvert, le systeme uClinux est disponible pour un grand nombre de 
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processeurs comme le ColdFire Motorola, la famille 68xxx, ARM, Intel i960, Axis ETRAX. 
Les nouvelles versions du noyau 2.6 sont tres rapidement integrees dans le projet. 

La page du projet est disponible sur http://www.uclinux.org. Le projet est sponsorise par la societe 
Arccturus Networks et un support commercial est disponible sur http://www.uclinux.com. 



RTLinux 



RTAI 



RTLinux est un projet Open Source qui a pour but d'ajouter a un noyau Linux standard un 
noyau temps reel preemptif et a priorites fixes. Ce petit noyau temps reel, chargeable dyna- 
miquement dans le systeme, considere le noyau Linux comme la tache de plus faible prio- 
rite. RTLinux a ete initialement developpe au departement d'informatique de l'lnstitut des 
mines et de technologie du Nouveau-Mexique par Victor Yodaiken et Michael Barabanov. 

Le produit ne peut plus vraiment etre considere comme un projet Open Source, puis la 
version GPL de RTLinux n'evolue quasiment plus par rapport a la version commerciale 
editee par FSMlabs (http://www.fsmlabs.com), societe fondee par les auteurs de RTLinux. 



RTAI utilise un principe similaire a RTLinux (principe de double noyau). A l'origine 
RTAI fut developpe a partir d'une version modifiee de RTLinux mais de nos jours c'est 
un projet tres dynamique, performant et totalement independant de RTLinux. A la diffe- 
rence de son homologue commercial, RTAI est un projet entierement libre. 



ELDK 



Le projet ELDK (Embedded Linux Development Toolkit) est maintenu par la societe alle- 
mande Denx Software (http://www.denx.de). Ce produit d'excellente qualite permet le deve- 
loppement du logiciel en developpement croise depuis un PC Linux x86 vers les architectures 
PowerPC (PPC) ou ARM. ELDK fournit egalement une image de systeme utilisable par NFS 
(Network File System). ELDK est decrit en details au chapitre 1 1 de cet ouvrage. 



PeeWee Linux 



Ce projet, disponible sur http://www.peeweelinux.org, est base sur la distribution Red Hat 6.2. 
II utilise une version standard du noyau 2.2 et n'inclut pas de fonctionnalites temps reel. 
Son principal attrait est l'existence d'un utilitaire de construction du systeme cible permet- 
tant de choisir les composants de maniere assez conviviale (interface similaire a la configu- 
ration du noyau Linux). II supporte les memoires flash de type DiskOnChip ou bien les 
peripheriques classiques IDE ou SCSI. Le site web du projet permet de telecharger une 
image du CD-Rom de la distribution. Ce projet faisait l'objet d'une presentation detaillee 
dans la premiere edition de cet ouvrage mais il est a ce jour obsolete et le chapitre 1 1 en 
question est remplace par une description des environnements de compilation croisee. 
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Tableau 2-1. Recapitulatifs des systemes embarques 



Nom 


Editeur 


Open 
Source 


Temps 
reel 


URL 


Remarques 


VxWorks 


Wind River 


Non 


Oui 


http://www.windriver.com 


Certainement le leader du marche 


pSOS 


Wind River 


Non 


Oui 


http://www.windriver.com 


Ancien mais tres repandu 


QNX 


QNX 


Partiel- 
lement 


Oui 


http://www.qnx.com 


Base sur UNIX, pas mal de 
composants Open Source, assez 
repandu, bonnes performances 


|iC/OS 


Micrium 


Non 


Oui 


http://www.ucos-ii.com 


Pour les micro-controleurs 


Windows CE 


Microsoft 


Non 


Oui 


http://www.microsoft.com/ 
windows/embedded 




LynxOS 


LynuxWorks 


Non 


Oui 


http:// 
www.lynuxworks.com 


Edite egalement BlueCat, base sur 
Linux 


Nucleus 


Accelerated 
Technology 


Oui 


Oui 


http://www.accelerated- 
technology.com 


Pas de royalties 


eCos 


Red Hat 


Oui 


Oui 


http://www.ecos. 
sourceware.org 


Utilisable pour de tres faibles 
empreintes memoire, environnement 
de developpement croise Linux dispo- 
nible 


PeeWeeLinux 


Aucun 


Oui 


Non 


http://www.peeweelinux.org 


Obsolete car fonde sur Red Hat 6.2, 
noyau 2.2 


RTLinux 


FSM Labs 


Oui 


Oui 


http://www.fsmlabs.com 


Existe en version GPL et version 
«pro», attention au brevet logiciel 
(patent), temps reel «dur» 


RTAI 


Aucun 


Oui 


Oui 


http://www.rtai.org 


Proche de RTLinux mais non 
ommercial 


TUXIA 


TUXIA 


Oui 


Non 


http://www.tuxia.com 


Dedie « Internet Appliance* 


Red Hat 
Embedded Linux 


Red Hat 


Oui 


Non 


http://ww.redhat.com/ 
embedded 




uOlinux 


Aucun 


Oui 


Oui 


http://www.uclinux.org 


Pour micro-controleurs sans MMU, 
sponsorise par Arcturus Networks. 
Existe en noyau 2.4 et 2.6 


Embedix 


Lineo 


Oui 


Non 


http://www.lineo.com 


Utilise dans le PDA Zaurus de 
SHARP 


Montavista Linux 
(Hard Hat) 


Monta Vista 


Oui 


Oui 


http://www.mvista.com 


Fonde sur des patches «preemptifs» du 
noyau Linux, pas de temps reel «dur» 


ELDK 


Denx 
Sofware 


Oui 


Non 


http://www.denx.de 


Environnement de developpement 
croise x86 vers ARM ou PowerPC 
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Quelques exemples de produits utilisant Linux 

Linux est present dans divers secteurs de l'industrie grand public. On peut citer 

• les assistants personnels ou PDA (Personal Digital Assistant) ; 

• les consoles multimedias et tablettes Internet (set top boxes et web pads) ; 

• les magnetoscopes numeriques. 

Dans des domaines plus professionnels, on peut citer : 

• les routeurs ; 

• les equipements de telephonie ; 

• les cameras IP. 



Les PDA 



Un des premiers modeles de PDA sous 
Linux fut le YOPI, developpe par le coreen 
Samsung. Le systeme utilise un processeur 
Strong ARM cadence a 206 MHz avec un 
minimum de 16 mega-octets de RAM et 
32 mega-octets de memoire flash. Au 
niveau logiciel, le YOPI utilise le systeme 
graphique standard X Window System opti- 
mise pour la circonstance. Contrairement a 
d'autres PDA pour lesquels il existe des 
versions de Linux remplacant le systeme 
initial, le YOPI est concu pour Linux. 

Plus recemment, Sharp a mis sur le marche 
le ZAURUS, un PDA utilisant une architec- 
ture similaire mais dont 1' interface est 
basee sur Java. Le systeme utilise un pro- 
cesseur StrongARM cadence a 206 MHz 
avec un minimum de 16 mega-octets de 
RAM et 32 mega-octets de memoire flash. 
II dispose de nombreuses extensions et d'un 
petit clavier integre. 




Figure 2-4 

Le YOPI de Samsung 



\rTTT\W 


1 1 a "i r- 1 

1\ <• O 1 ' 1 1 1 

' a "s * 1 


Bt?j 



Figure 2-5 

Le ZAURUS de SHARP 
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On ne peut pas ne pas citer le celebre iPAQ, produit phare developpe par Compaq. II n'est 
pas a ce jour diffuse par Compaq en version Linux mais avec Windows CE. Un portage 
de Linux et de 1' interface graphique X Window System est cependant disponible comme 
l'indique la figure 2-6 ci-apres. 




Figure 2-6 

iPAQ sous Linux et X 

Plus generalement, les differents travaux concernant le portage de Linux et le develop- 
pement d' applications Linux sur les PDA sont accessibles sur le site http://www.hand- 
helds.org. 



Les consoles multimedias et tablettes Internet 

Ericsson a developpe une tablette Internet utilisant une 
connexion sans fil (BlueTooth). Le systeme est archi- 
tecture autour d'un StrongARM cadence a 206 MHz, 
32 mega-octets de RAM et 32 mega-octets de memoire 
flash. II utilise la bibliotheque Qt-Embedded, le navi- 
gateur Opera et Embedded Linux de Red Hat. 

La societe francaise NETGEM (http://www.netgem. 
com) a developpe une set top box (la NETBOX) utili- 
sant initialement un systeme d' exploitation proprie- 
taire. Lenvironnement graphique fut ensuite porte sur 
une version de Linux adaptee par NETGEM. La ver- 
sion actuelle utilise Hard Hat Linux de Monta Vista 
(http://www.mvista.com). NETGEM diffuse egalement 




Figure 2-7 

Tablette Internet par Ericsson 
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la suite logicielle NETGEM 4.0 basee sur Linux et destinee a l'integration de fonctionna- 
lites Internet dans les televiseurs. 



Les magnetoscopes numeriques 

La societe americaine TiVo (http://www.tivo. 
com) a developpe un systeme d'enregistre- 
ment numerique permettant l'enregistrement 
simultane de divers canaux de television. Le 
stockage s'effectue sur un disque dur opti- 
mise pour les temps d'acces. L'interface de 
navigation, tres conviviale, permet de pro- 
grammer les enregistrements en fonction des 
gouts de l'utilisateur et de construire ainsi 
une television virtuelle basee sur les enregis- 
trements. 



Figure 2-9 

Interface de TiVo 




Figure 2-8 

Magnetoscope TiVo 
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La societe Replay TV (/?ffp://n/ivn/.rep/ayfi'.com) a developpe un produit similaire. 



Les routeurs 



Le leader mondial des routeurs (CISCO Systems, http://www.cisco.com) utilise pour ses 
routeurs professionnels un systeme proche de la famille Unix, IOS. La gamme CISCO/ 
Linksys est par contre basee sur Linux et les sources du systeme sont disponibles sur le site 
de la societe (http://www.linksys.com). Ce produit est aujourd'hui un des leaders du marche 
des routeurs xDSL/Wi-Fi. 

Le projet Open Source Linux Router (http://www.linuxrouter.org) a developpe une distribu- 
tion reduite permettant de construire un routeur efficace et a bon marche a partir d'un PC 
classique. Ce projet LRP (Linux Router Project) est parfois considere comme une distri- 
bution embarquee a part entiere. 
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Figure 2-10 

Routeur CISCO/Linksys 




Figure 2-11 

Routeur xDSL de Lightning 




La societe Suisse Lightning (http://www.lightning.ch) developpe une gamme de routeurs uti- 
lisant Linux comme systeme embarque. 

De nombreux operateurs Internet francais comme Free SA, Neuf Telecom Cegetel ou Wana- 
doo fournissent des modems ADSL multi-fonctions (Freebox, Neuf box, C-Box, Livebox). 

Ces « boites noires » permettent non seulement l'acces ADSL mais aussi l'acces local 
sans fil (Wi-Fi), la telephonie sur IP (VoIP) ou bien l'acces a la television numerique 
(decodage MPEG2). 

La Freebox de Free SA est certainement le produit 
le plus repandu. Ses specifications techniques avan- 
cees restent assez mysterieuses car Free communi- 
que peu sur ce point. Cependant l'utilisation de 
Linux dans ce terminal ne laisse aucun doute. Par 
defaut la Freebox se comporte en « proxy DHCP » 
et permet done a l'utilisateur d'obtenir de maniere 
transparente une adresse IP aupres du point d'acces 
Internet (DSLAM pour Digital Subscriber Line 
Access Multiplexor) de Free. II est egalement possi- 
ble de configurer la Freebox de maniere a ce qu'elle se comporte comme un veritable rou- 
teur permettant de connecter a Internet plusieurs machines d'un reseau local prive masque 
par la Freebox. La majeure partie des composants Linux de la Freebox est obtenue aupres 
du DSLAM lors de la mise sous tension ce qui fait que les diverses configurations sont 
effectuees au travers de l'espace de l'abonne sur le site de Free SA. 

Outre les fonctions classiques d'acces a 1' internet haut-debit, la Freebox inclut des fonc- 
tionnalites interessantes et evolutives. La description des services est disponible sur le 
site de Free a 1' adresse http://freebox.free.fr. 

Acces Wi-Fi 

II est possible d'ajouter une carte Wi-Fi PC-Card dans la Freebox (V3 et V4) afin de 
transformer la boite en routeur Wi-Fi. La configuration s'effectue au travers de l'espace 
abonne sur le site de Free. 



Figure 2-12 

Freebox de Free SA. 
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Telephonie illimitee 

La Freebox utilise la connexion ADSL pour permettre l'acces telephonique en « voix sur 
IP » (VoIP). Pour cela, il suffit de connecter un combine telephonique classique sur la 
Freebox par un simple cable RJ1 1. II est bien entendu possible de recevoir des appels sur 
un numero special affecte par l'operateur qui n'a rien a voir avec le numero associe a la 
ligne telephonique classique qui peut etre geree par un autre operateur (cas de ligne non 
degroupee). 

Television et multimedia 

On peut raccorder la Freebox a un televiseur ou a une carte d' acquisition video a la 
norme PAL. L utilisation du service s'effectue grace a une telecommande livree avec la 
Freebox. Au niveau multimedia, Free met a disposition depuis peu le logiciel Freeplayer qui 
permet de diffuser sur un televiseur des contenus multimedias provenant d'un ordinateur. 

Quelques informations techniques 

Voici quelques informations concernant la structure materielle et logicielle de la Freebox. 
Ces informations proviennent de la societe Free SA. 

Le materiel 

Historiquement, il existe 4 versions de la Freebox (Via V4). Les Freebox VI et V2 uti- 
lisent un processeur MIPS (IDT RC32355), 16 Mo de memoire vive et 4 Mo de memoire 
flash. La gestion de la ligne DSL est assuree par un DSP. La television est geree par un 
deuxieme processeur specifique (ST5518) utilisant un systeme d' exploitation proprie- 
taire. La communication entre les deux processeurs est assuree par un FPGA. La partie 
telephonie est egalement geree par un DSP. Ces versions sont equipees d'une interface 
Ethernet 10/100 Mbps et d'une interface USB « device ». 

La Freebox V3 est munie d'un processeur ARM sans MMU et de 8 Mo de memoire vive. 
Dans ce cas, la gestion de la ligne DSL est integree au processeur. Cette version possede 
un afficheur en facade permettant de suivre l'etat de demarrage du systeme (detection de 
ligne, connexion DSLAM, mise a jour logiciel, authentification). Elle inclut egalement 
un port PCMCIA destine a recevoir l'extension Wi-Fi. 

La version V4 est pourvue d'un processeur MIPS et de 16 Mo de memoire vive. Cette 
version possede un port PCMCI/Cardbus ainsi qu'un port USB « host ». L'interface 
Ethernet est en 100 Mbps. 

Le logiciel 

La distribution Linux employee dans la Freebox a ete entierement creee par les equipes 
techniques de Free SA. Cette distribution utilise un systeme de generation inspire par 
l'utihtaire buildroot (voir http://buildroot.uclibc.org). Cet utilitaire est constitue d'un ensemble 
de fichiers Makefile et pitch permettant d'automatiser la generation d'une chaine de 
compilation croisee et du systeme de fichiers principal. 
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La distribution utilise uclibc (http://www.uclibc.org) qui est une version plus reduite de la 
libc que la glibc habituellement mise en oeuvre sous Linux. Le compilateur utilise est 
le 3.3.5. 

L' architecture est constitute d'un noyau Linux minimal resident en memoire permanente 
(flash). A chaque demarrage de la Freebox, ce noyau telecharge un noyau plus complet 
aupres du DSLAM, ce qui permet d' assurer la presence du dernier logiciel « firmware » 
dans la Freebox. 



La telephonie 

La societe APLIO (http://www.aplio.com) a deve- 
loppe un equipement de telephonie Internet base 
sur une distribution Linux embarquee tournant sur 
un ARM7DTMI cadence a 20 MHz. Ce systeme 
tres reduit n' utilise pas d' interface graphique et 
occupe seulement 2 mega-octets de memoire flash 
et 4 mega-octets de RAM. 

Independamment de cet equipement tres particu- 

lier, certains constructeurs de centraux telephoniques professionnels (PABX) utilisent 

d'ores et deja des composants Linux. 



Figure 2-13 

Telephone IP par APLIO 




Les cameras IP 



Le principe d'une camera IP est de transformer 
1' information analogique filmee par la camera en 
un flux de donnees numeriques exploitables par 
un systeme informatique connecte sur un reseau 
de type IP. Ces produits utilisent le plus souvent 
un format MJPEG (pour Motion JPEG) qui est 
constitue d'une suite d' images JPEG. La societe 
suedoise AXIS (http://www.axis.com) a developpe 
une camera autonome comportant un systeme 
optique et un systeme d' exploitation Linux porte 
sur le processeur ETRAX, developpe par AXIS. 
La camera inclut un serveur HTTP qui permet un 
acces direct a partir de n'importe quel navigateur. 




Figure 2.14 

La camera IP AXIS 
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Tableau 2-2 Recapitulatifs de quelques produits bases sur LINUX 



Norn 


Type 


Fabricant 


URL 


Remarques 


YOPI 


PDA 


SAMSUNG 


http://www.yopi.com 


Un des premiers PDA Linux, 
voir http://www.handhelds.org 


Zaurus 


PDA 


SHARP 


http://www.sharp.co.uk 


Utilise Lineo et le navigateur Opera, 
voir http://www.handhelds.org 


IPAQ 


PDA 


Compaq 


http://www.compaq.com/products/ 
iPAQ 


Pas initialement sous Linux, 
voir http://www.handhelds.org 


Bahia MPA 


PDA 


Silink 


http://www.servelinux-fr.com/ 
apropos/silink/ 


Toolkit disponible 


Iplayer 


Set top box 


NetGem 


http://www.netgem.com 




TiVo 


Magnetoscope 
numerique 


TiVo 


http://www.tivo.com 


Permet de construire un pro- 
gramme TV «virtuel» 


ReplayTV 


Magnetoscope 
numerique 


ReplayTV 


http://www.replaytvcom 


Proche de TiVo 


LinuxRouter 


Routeur 


Aucun 


http://www.linuxrouter.org 


Distribution pour construire un 
routeur a base de Linux reduit. 
Tient sur une disquette 


MultiCom 


Routeur 


Lightning 


http://www.lightning.ch 


Routeur xDSL 


Linksys 


Routeur 


CISCO/ 
Linksys 


http://www.linksys.com 


Routeur xDSL/Wi-Fi, Sources Linux 
disponibles 


Freebox 


Routeur 


Free SA 


http://www.free.fr 


Routeur/modem xDSL multi-fonction 


Aplio 


Telephone IP 


Aplio 


http://www.aplio.com 




Axis 2100 


Camera IP 


AXIS 


http://www.axis.com 


Integre un serveur http 



En resume 



Les systemes embarques proprietaries subissent certaines contraintes et ont en particulier 
quelques difficultes a suivre revolution technologique. Les logiciels Open Source ont de 
nombreux avantages, notamment en matiere de disponibilite des sources et d' absence de 
royalties. 

L'utilisation de l'Open Source pour les systemes embarques necessite quelques precau- 
tions, surtout au niveau du support technique. De par des qualites reconnues, Linux est le 
plus souvent tres bien adapte aux applications embarquees. II sera cependant inadapte si 
l'empreinte memoire disponible est trop reduite. 

De nombreuses distributions Linux adaptees a l'embarque existent deja, soit sous forme 
de projets Open Source, soit sous forme de produits commerciaux (egalement Open 
Source le plus souvent). 

De meme, de nombreux produits industriels recourent a Linux dans des domaines aussi 
varies que les PDA, les set top boxes, les equipements multimedias, les routeurs ou la 
telephonie. 
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Choix materiels pour un 
systeme Linux embarque 



Le chapitre precedent nous a permis de demontrer que Linux est un tres bon choix pour 
un systeme embarque. Le present chapitre va etre consacre a la description des choix 
materiels (hardware) les mieux adaptes a cet environnement. 



Attention 

II va sans dire que les marques citees dans ce chapitre ne le sont pas a des fins publicitaires. Elles correspon- 
dent seulement a des produits utilises par I'auteur pour des applications reelles. 



Choix dune architecture, PC ou non ? 

Le monde de l'informatique est domine par 1' architecture dite PC heritee des systemes 
personnels initialement developpes par IBM au debut des annees 1980. En depit des 
nombreux detracteurs et autres analystes qui prevoient sa fin proche, 1' architecture PC a 
su s' adapter a revolution technologique en balayant sur son passage bon nombre de con- 
currents pourtant presentes comme revolutionnaires. 

Dans le monde de l'ordinateur personnel, seul 1'iMac d'Apple se taille une petite part de 
marche - bien inferieure a 10 % - au milieu de la deferlante des compatibles PC. Les rai- 
sons de ce succes durable du PC sont diverses : 

• Le PC est depuis le debut une architecture ouverte, ce qui a permis tres rapidement le 
developpement de machines compatibles a bas prix et done d'imposer 1' architecture 
sur un grand nombre de marches, du tres bas de gamme aux systemes professionnels. 
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Par opposition, d'autres concurrents ont jalousement garde leurs secrets et interdit la 
realisation de clones, ce qui a limite la diffusion a des marches plutot haut de gamme. 
Ce qui est vrai pour l'architecture de base (la carte mere) Test encore plus pour les 
peripheriques comme les cartes d' extension, vendues souvent a des prix prohibitifs sur 
les architectures non-PC. Le fait est que bon nombre d' architectures concurrentes ont 
maintenant adopte des composants de l'architecture PC, comme le bus PCI (Periphe- 
ral Component Interconnect), permettant l'utilisation de peripheriques tres compe- 
titifs. 

• Le PC a longtemps ete exclusivement associe ou presque aux systemes d' exploitation 
de Microsoft, la fulgurante ascension du PC decoulant de ce qu'il ait ete choisi pour 
developper le systeme d' exploitation DOS pour le premier IBM PC. Le fait est que les 
systemes de Microsoft sont depuis longtemps les plus repandus et qu'ils existent pres- 
que exclusivement sur architecture PC. 

• Enfin, le PC est depuis toujours associe au processeur Intel ou compatible. Intel s'est 
longtemps comporte en « Microsoft du processeur » agissant en quasi-hegemonie sur 
ce marche. II est aujourd'hui talonne par d'autres fondeurs comme AMD, mais ces 
derniers se doivent de fournir des processeurs les plus compatibles possibles tout en 
restant plus performants que ceux d' Intel. 

Le probleme est different dans le monde de l'embarque pour lequel l'architecture Intel/ 
PC n' a jamais eu - ou n'a pas encore - la position hegemonique qu'elle connait dans le 
monde de l'informatique classique. Une des raisons tient au processeur car Intel s'est for- 
tement concentre sur le marche du PC classique et ses produits ne remplissent pas tou- 
jours les contraintes de performance, consommation et dissipation thermique necessaires 
a certains environnements embarques. En ce qui concerne des architectures de meme 
niveau de complexite, le processeur PowerPC codeveloppe par IBM et Motorola et uti- 
lise dans la gamme Macintosh d' Apple est egalement tres utilise dans le monde industriel 
en raison de son tres bon rapport consommation/performances. 

L autre raison a trait a l'architecture elle-meme. Le principal interet du PC est le cote 
interchangeable et banalise de ses composants. Le developpeur ou la secretaire qui utilise 
sa machine dans un environnement stable et securise (pas de contrainte d'humidite, de 
vibration ou de temperature) pourra aisement remplacer une carte mere par une autre, 
equivalente, et ce a tres bon prix. Le plus souvent, les systemes sont en fait peu sollicites 
car utilises seulement quelques heures par jour. Les systemes plus sollicites comme les 
serveurs sont places dans des conditions de fonctionnement encore plus ideales, souvent 
dans des salles climatisees, et choyes par des administrateurs systeme soucieux de leur 
bien-etre. 

II en va autrement pour nombre de systemes embarques, contraints de fonctionner 24 heures 
sur 24 dans des environnements beaucoup plus agressifs. Ce dernier point peut conduire 
a l'utilisation de composants de meilleures qualites (on parle de « PC industriel »), done 
bien plus onereux. Le mythe du PC a bon marche, banalise et multi-usage que Ton peut 
acheter au revendeur du coin ou pour trois fois rien a Taiwan en prend un coup, meme si 
5a decoit profondement votre patron ou votre responsable des achats. . . 
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Faut-il done delaisser 1' architecture PC ? Certainement pas. Quelle que soit Tissue du 
developpement d'un projet de systeme embarque, il est un domaine sur lequel le PC reste 
imbattable, celui du maquettage et de la simulation. Meme si le systeme final utilise un 
processeur PowerPC ou StrongARM sur une carte etudiee par vos soins, il y a gros a 
parier que les premieres versions seront developpees sur architecture PC. De meme, sur 
de petites series ou des systemes fonctionnant dans des conditions exterieures raisonna- 
bles, le choix d'une architecture PC reste economique et tres viable d'un point de vue 
technique. 

En resume, les regies d'or a respecter sont les suivantes : 

• Sauf cas exceptionnel, utilisez une architecture PC pour la phase de maquettage et 
d' etude de fonctionnalite. II est toujours plus facile et souvent moins onereux de mon- 
trer une maquette tournant dans un PC portable sous Linux que sur un prototype qui 
refusera de fonctionner a plus d'un kilometre de votre bureau d' etude. 

• N'essayez pas d' adapter votre projet a 1' architecture PC, ou faites-le dans des limites 
tres raisonnables. 

• Linux est certainement le systeme le plus disponible sur nombre de processeurs, en 
tout cas pour la plupart de ceux utilises dans des environnements embarques. De plus, 
le portage du noyau Linux vers un nouveau processeur est un travail relativement aise 
de par la litterature consequente et les nombreux travaux realises dans ce domaine. Ce 
point est egalement vrai pour la chaine de developpement GNU (gec et gdb). 

• Limitez une etude materielle a une production importante ou bien prenez de serieuses 
garanties sur le prix de vente. 



Choix du processeur : MMU ou non ? 

Le concept du MMU 

Linux a ete initialement developpe sur la base du mecanisme de memoire protegee du 
processeur Intel 80386. Ce mecanisme, qui repose sur un composant materiel appele MMU 
{Memory Management Unit), permet a un processus de ne jamais ecraser l'espace memoire 
d'un autre processus. La MMU autorise la conversion entre les adresses physiques - adresses 
effectivement utilisees dans la machine - et les adresses logiques - adresses vues par le 
processus et allouees par le systeme d' exploitation. Si un processus tente de sortir par 
erreur de l'espace memoire qui lui est accorde, la MMU detecte l'erreur et stoppe le pro- 
gramme en generant une erreur de « violation de segmentation » {segmentation violation 
ou SIGSEGV). De ce fait, un programme tournant sous Linux dans l'espace dit « utilisa- 
teur » - par opposition a l'espace « noyau » - ne peut jamais « planter » le systeme. 

Les versions courantes du noyau Linux sont prevues pour fonctionner sur des proces- 
seurs avec MMU, ce qui concerne la majorite des processeurs utilises dans la micro- 
informatique classique et aussi dans un bon nombre d' applications embarquees. En 
revanche, ces processeurs sont en general plus gourmands en ressources materielles, et 
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certaines applications dites « profondement enfouies » (deeply embedded) ne pourront 
utiliser que des processeurs depourvus de MMU. 

II existe bien entendu des systemes d' exploitation dedies a ces micro-controleurs - uC/OS 
en est un tres bon exemple - mais ceux-ci sont en general bien plus limites que Linux au 
niveau des protocoles standards et de l'interoperabilite avec le monde exterieur. 

fjClinux: Linux sans MMU 

Un portage du noyau Linux est cependant disponible pour les processeurs depourvus de 
MMU : uClinux - pour Micro-C Linux (Linux pour micro-controleurs) mais a prononcer 
You see Linux (http://www.uclinux.org). Le portage est initialement base sur la version 
2.0.38 du noyau Linux mais des versions basees sur les noyaux 2.4 et 2.6 sont egalement 
disponibles. 

L API du systeme est identique au vrai noyau Linux bien que uClinux utilise une libC - 
bibliotheque de base de programmation - differente de la glibc de la version standard de 
Linux. La motivation est toujours la meme : le gain d'espace, lorsqu'on sait que les ver- 
sions recentes de la glibc ont une taille largement superieure au mega-octet. La principale 
limitation de uClinux par rapport a Linux est 1' absence de protection de memoire entre 
les processus mais egalement avec le noyau. De ce fait, une application erronee pourra 
facilement « planter » le systeme. L'utilisation du systeme uClinux sera detaillee dans la 
deuxieme partie de cet ouvrage, au chapitre 10. 

Les processeurs compatibles x86 

Concernant les processeurs avec MMU, et outre les classiques Pentium et autres Celeron 
fournis par Intel, de nombreux fondeurs comme AMD (http://www.amd.com), National 
Semiconductor (http://www.national.com) ou VIA (http://www.viavpsd.com) proposent des 
processeurs compatibles x86 souvent d'un excellent rapport qualite/prix. 

Le processeur ELAN520 developpe par AMD est deja tres implante dans le monde des 
applications embarquees a faible cout. II est annonce comme officiellement compatible 
LINUX sur le site AMD (http://www.amd.com/epd/linux). 

Le processeur Geode developpe par National equipe un grand nombre de cartes mere 
industrielles dont les cartes PC/104 citees plus bas. 

Le nouveau processeur VIA C3 cadence a 1 GHz peut egalement etre un choix tres inte- 
ressant (http://www.via.com.tw/en/viac3/c3.jsp). II est d'ores et deja integre sur des cartes 
mere a tres faible cout. Le site http://www.viaarena.com regroupe deja un grand nombre 
d' informations sur ce processeur. Une section dediee a Linux est egalement disponible 
sur le site. 

Bien que moins puissant (il est detecte comme compatible 486 par le noyau Linux), le 
processeur STPC (http://www.st.com/stpc) est egalement un choix interessant pour des 
applications ne demandant pas de fortes puissances de calcul. 
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La societe Transmeta (employeur de Linus Torvalds) commercialise un processeur a 
faible consommation, compatible x86, et oriente embarque, appele Crusoe. Une distri- 
bution Linux est disponible pour cette architecture (Midori Linux), voir http://www.trans- 
meta.com/developers. 

Les autres processeurs 

L' architecture x86 n'est pas forcement la meilleure pour toutes les applications, loin s'en 
faut. Dans le cas de la production d'une serie de cartes mere assez importante (plusieurs 
milliers d'exemplaires) ou d'un besoin particulier (faible consommation, integration), 
d'autres processeurs sont plus avantageux. Nous pouvons citer l'architecture PowerPC 
(PPC) largement utilisee dans les applications industrielles. 

Concernant des applications tournant sur des cartes mere de taille reduite, l'architecture 
ARM est de plus en plus utilisee sous diverses formes (ARM7, ARM9, XSCALE, etc.). 
Ces processeurs ont un bon niveau d'integration, une faible consommation et permettent 
done la conception de cartes mere plus simples et moins couteuses que les x86. Le pro- 
cesseur AT91RM9200 produit par la societe ATMEL (http://www.atmel.com) en est un bon 
exemple car il integre en standard un controleur Ethernet 10/100 Mbits/s, une interface 
USB host et une interface USB device. 



La memoire de masse 

La memoire de masse est utilisee pour stacker 1' image du systeme d' exploitation et les 
donnees lues ou ecrites au cours du fonctionnement de ce systeme. Les systemes de 
micro-informatique classiques utilisent des disques durs compatibles avec les standards 
de bus IDE (Integrated Drive Electronics) ou SCSI (Small Computer System Interface). 

La problematique des systemes embarques est differente car ils utilisent en general un 
faible espace de stockage, du moins pour le systeme d' exploitation. La ou les distribu- 
tions classiques installent plus d'un giga-octet de programmes sur des disques dont le 
moins volumineux accepte jusqu'a 10 Go, les distributions Linux embarquees se situent 
entre 2 et 10 Mo et les peripheriques de stockage sont de ce fait tres differents. 

D'autres facte urs peuvent egalement etre determinants : 

• la fragilite des disques durs lorsqu'ils sont utilises dans des environnements mobiles ; 

• la consommation d'energie et la dissipation fhermique ; 

• le bruit genere par les disques classiques. 

Les systemes embarques utilisent dans la plupart des cas des memoires permanentes 
appelees « memoires flash » (flash memory). La facilite d'utilisation des flash est simi- 
laire a celle de la memoire vive bien que son cofit soit bien superieur. La memoire flash 
peut se presenter sous differentes formes : 
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Figure 3-1 

DOC2000 de M-Sy stems. 



Des circuits ou chips classiques directement 

soudes sur la carte mere ou des circuits amovi- 

bles comme les DiskOnChip de chez M-Sys- 

tems (http://www.m-sys.com). Dans ce cas, le 

noyau Linux doit contenir un pilote de periphe- 

rique - ou driver - dedie. La photo ci-apres 

montre la memoire flash DOC2000 de M-Sys- 

tems existant actuellement pour des capacites 

allant de 16 a 568 Mo. M-Systems supporte 

officiellement le noyau Linux et fournit en telechargement les composants logiciels 

(patch) necessaires a l'ajout du pilote aux noyaux 2.0, 2.2 et 2.4. Les noyaux Linux 2.4 

et 2.6 contiennent egalement le pilote MTD (Memory Technology Devices) utilisable 

sur un grand nombre de memoires flash dont les DiskOnChip. 

Des circuits integres dans des boitiers standards comme les CompactFlash ou des 
boitiers compatibles avec la geometrie des disques durs 2,5 pouces utilises dans les 
ordinateurs portables. Dans ce cas, les disques flash sont le plus souvent accessibles en 
utilisant une interface IDE standard, ce qui evite l'ajout d'un pilote et facilite V integration 
sur des PC classiques lors des phases de developpement. 



Figure 3-2 

CompactFlash 
avec interface IDE. 





Figure 3-3 

Disque Flash IDE 2,5 pouces. 
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Outre le prix, les memoires flash ont cependant quelques limitations par rapport a la 
memoire vive : 

• le temps d'acces, en particulier pour la phase d'ecriture, est superieur a celui de la 
memoire vive ; 

• la duree de vie de la « flash » est fortement influenced par le nombre d'ecritures par 
unite de temps. Le site de M-Systems fournit une page permettant d'evaluer la duree 
de vie de ses produits en fonction du type, de la capacite et la frequence d'ecriture. 

Les bus d'extension et de communication 
Les bus d'extension ISA et PCI 

L' architecture Intel (entre autres) fournit differents bus d'extension et de communication. 
L'ancien bus ISA (Industry Standard Architecture) est souvent present sur les cartes mere 
dites « industrielles » a cause de la necessaire compatibility avec d'anciennes cartes 
d'extension faiblement diffusees. Ce bus a cependant tendance a disparaitre et il n'est 
plus disponible sur les cartes mere grand public a plus bas cout. Dans la mesure du pos- 
sible, il est preferable d'utiliser un bus PCI qui est beaucoup plus facile a manipuler sous 
Linux car bien plus recent et done effectuant automatiquement la plupart des initialisa- 
tions materielles, comme les niveaux d'interruption. Si cela est necessaire, le developpe- 
ment d'un pilote de carte PCI sous Linux est relativement aise (plus qu'en ISA) car 1' API 
du noyau propose un grand nombre de fonctions de haut niveau. Pour des informations 
plus completes concernant le developpement de tels pilotes, nous vous renvoyons a 
l'excellent ouvrage d'Alessandro Rubini, Linux Device Drivers, disponible en ligne 
a 1' adresse http://www.xml.com/ldd/chapter/book et http://www.oreilly.com/catalog/linuxdrive2. 

Ajoutons a cela que le debit disponible sur le bus PCI est beaucoup plus important que celui 
du bus ISA (jusqu'a 1 Go/s contre 8 Mo/s). Certaines cartes miniatures proposent un bus au 
format dit CompactPCI qui propose les memes caracteristiques que le bus PCI avec un 
encombrement mecanique plus faible, meme si le cout des cartes est plus eleve. Le debit est 
egalement plus faible que celui du PCI classique puisqu'il est limite a 132 Mo/s. 

Les ports series 

Les ports series RS-232 sont traditionnellement tres utilises dans les systemes embarques 
de par leur anciennete et leur facilite de mise en oeuvre. Pour la meme raison que le bus 
ISA, ils ont cependant tendance a disparaitre du materiel grand public au profit de bus 
plus modernes comme l'USB. La plupart des cartes mere proposent cependant au moins 
un port serie et il est aise d'ajouter des cartes d'extensions au format ISA ou PCI. Ces 
cartes peuvent etre equipees de controleurs classiques de type 16550A, et le noyau Linux 
pourra les piloter sans aucune modification a partir du moment ou le support du port serie 
standard est active dans la configuration du noyau. La detection des ports peut etre veri- 
fiee au moyen de la commande suivante : 

I# dmesg | grep tty 
ttySOO at 0x03f8 (irq = 4) is a 16550A 
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La commande Linux setseri al permet egalement de manipuler les ports series detectes. 

I it setserial /dev/ttySO 
/dev/ttySO, UART: 16550A, Port: 0x03f8, IRQ: 4 

Le noyau Linux inclut egalement le support d'un grand nombre de cartes series dites 
« multi-voies » et permettant d' ajouter un plus grand nombre de ports series sur une seule 
carte d'extension (de 4 a 16). Dans ce cas-la, les options adequates doivent etre validees 
dans la configuration du noyau (mike xconf i g) dans la rubrique Character devices. 

Le bus USB 

Le bus USB (Universal Standard Bus), recemment introduit, presente un certain nombre 
d'avantages tant au niveau de la possibilite de connecter des peripheriques « a chaud » 
que du debit disponible (environ 1,2 Mo/s). II est tres repandu dans les systemes grand 
public depuis Windows 98 sur PC ou 1'iMac. Le support de l'USB sur Linux n'est officiel 
que depuis la version 2.4 et tous les peripheriques ne sont pas supportes (loin de la) car 
cela necessite le developpement d'un pilote et done de disposer des specifications mate- 
rielles du peripherique. Dans tous les cas, meme si les specifications sont allechantes, il 
est assez peu recommande dans des applications sensibles car sa stabilite n'est pas 
encore au niveau du support PCI, ISA ou Ethernet. La liste des peripheriques supportes 
est cependant disponible sur le site http://www.linux-usb.org. 

Les autres bus : I2C, 120, IEEE 

De nombreux autres supports bus et protocoles associes sont disponibles d'ores et deja dans 
l'arborescence officielle des sources du noyau Linux. Meme si le support de certains bus est 
eprouve (I2C), la realisation d'un projet integrant un bus de ce type devra passer par la vali- 
dation de l'etat du support en consultant la page web associee au projet. Les pointeurs sont 
en general disponibles dans le repertoire Documentation des sources du noyau Linux. 

Nous pouvons citer ici quelques pointeurs interessants concernant le support de divers 
formats de bus sur Linux. 

• La page du Linux Lab Project sur http://www.llp.fu-berlin.de. Ce projet concerne le 
developpement de divers bus industriels sur Linux. 

• La page du bus IEEE1394 appele aussi Fire Wire. Est situee sur http://linux1 394. source- 
forge, net. Le support est disponible dans le noyau 2.4. Le debit de ce bus de plus en 
plus utilise est d'environ 50 Mo/s. 

Les cartes PC/104 

Le format PC/104 est apparu en 1992 ; e'est en fait une version compacte du format PC 
classique. Le principe du PC/104 est de fournir des modules de petite taille que Ton peut 
empiler les uns sur les autres. Lencombrement d'une carte PC/104 est comparable a 
celui d'une disquette 3,5 pouces (90 sur 96 mm), ce qui permet de construire des syste- 
mes tres peu volumineux. 
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Le PC/ 104 utilise initialement le format de bus ISA ; cependant, il existe une evolution 
du format, appelee PC/104-Plus, qui permet de disposer en plus des connecteurs ISA 
d'un connecteur PCI. Le nom du format a pour origine la somme du nombre de broches 
disponibles sur le bus ISA de la carte PC/104, soit 40 plus 64. 

Le schema ci-apres donne un exemple d'empilage de trois cartes PC/104. 



Figure 3-4 

Configuration PC/104 a 3 cartes. 
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Le schema ci-apres indique la geometrie d'une carte PC/104-Plus avec connecteur PCI 
(J3), ainsi que les deux connecteurs ISA du format PC/104 classique (Jl et J2). 
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Figure 3-5 

Carte PC/104-Plus. 



Le principal avantage du format PC/104 est sa forte similitude avec 1' architecture PC stan- 
dard. Des cartes mere integrees disposeront de toutes les interfaces classiques (disque dur 
IDE 2,5 pouces, CompactFlash IDE, lecteur de disquette, controleur Ethernet, USB, port 
serie et parallele, connecteurs VGA, clavier et souris PS/2), ce qui permettra de migrer tres 
facilement d'un environnement de developpement vers l'environnement embarque definitif. 
De par sa forte integration, ce type de carte est cependant relativement onereux. 
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La societe Advantech (http://www.advantech.com) est leader sur le marche des cartes pro- 
cesseurs PC/ 104. La carte PCM-3350 decrite ci-apres est basee sur un compatible proces- 
seur NS Geode a 300 MHz (compatible x86 Intel) et dispose de toutes les interfaces d'un 
PC classique ainsi que d'un connecteur CompactFlash vu comme un disque IDE. La 
carte dispose egalement d'un connecteur memoire DIMM (Dual In-line Memory 
Module), standard permettant d'utiliser jusqu'a 128 Mo de RAM. 



Figure 3-6 

Carte Advantech PCM- 
3350. 
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La page du consortium PC/ 104 contenant la liste des fabricants est disponible sur http:// 
www.pc104.org. 



Les cartes DIL 



Ces cartes permettent un tres haut niveau 
d' integration car elles integrent un systeme 
complet sur un format DIL (Dual In Line) 
a 64 broches, comme cela est indique sur 
le schema ci-contre. 

La carte existe en version compatible 
Intel 486 et StrongARM. Elle est tres bien 
adaptee a des applications reseau car elle 
contient un controleur Ethernet et peut 
gerer jusqu'a trois ports series. La tension 
d' alimentation n'est que de 5 V. La carte 
est equipee de 2 Mo de flash et 8 Mo de 
RAM. 
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Figure 3-7 Carte DIL. 



La societe SSV-Embedded (http://www.ssv-embedded.de) propose un kit devaluation 
contenant une version de Linux (noyau 2.2) adaptee a ce type de carte. La configuration 
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standard est basee sur une distribution DOS tres legere qui permet de demarrer Linux 
depuis DOS grace a l'utilitaire LOADLIN. L' utilisation de LOADLIN sera detaillee dans 
la deuxieme partie de l'ouvrage, au chapitre 8. 

Des informations sur ce produit sont disponibles sur http://www.dilnetpc.com. Le site est 
extremement bien documente et contient un grand nombre de documents techniques a 
telecharger au format PDF. 



Les cartes uCsimm 

Le format uCsimm est un format micro-controleur 
SIMM (Single In-line Memory Module) a 30 bro- 
ches developpe autour de uClinux, portage du 
noyau Linux pour les processeurs depourvus de 
MMU. Le module utilise un processeur Moto- 
rola DragonBall 68EZ328 et dispose de 2 Mo de 
flash et 8 Mo de RAM. 

Des kits devaluation et de developpement sont 
disponibles sur http://www.uclinux.com/orderdesk. 




Figure 3-8 

Module uCsimm, 





Tableau 3-1. Recapitulatifs de quelques composants materiels 


Nom 


Type 


Fabricant 


URL 


Remarques 


Geode 


Processeur 
compatible x86 


National 
Semiconductor 


http://www.national.com 


Derive du Cyrix MediaGX 


VIAC3 


Processeur 
compatible x86 


VIA 


http://www. via. com. tw/en/ 
viac3/c3.jsp 


Excellent rapport performance/consomma- 
tion. Derive du MediaGX 


Elan 520 


Processeur 
compatible x86 


AMD 


httpj/www. amd. com/epd/ 
iinux 


Tres repandu 


STPC 


Processeur 
compatible x86 


ST 


http://www. st. com/stpc 




ARM 

AT91RM9 

200 


Processeur 
famille ARM9 


ATMEL 


http://www.atmel.com 


Bon processeur industriel. Integre un 
controleur Ethernet, un controleur USB host 
et device 


Mini-ITX 


Carte mere 


EPIA/VIA 


http:llwww. viavpsd. com 


Basee sur le VIA C3, tres bon rapport perfor- 
mance/prix 


Disk On 
Chip 


Memoire flash 


M-Systems 


http://www.msys. com 


Support dans le noyau 2.4 (sauf Millenium 
Plus) ou chez M-Systems (patch noyau). 
Attention au probleme de GPL dans le cas 
du patch M-Systems 


Compact- 
Flash 


Memoire flash 


Plusieurs 


httpj/www.compact- 
flash.org 


En general avec interface IDE, done pas de 
pilote a ajouter 


PC/104 


Cartes mere 


Plusieurs 


http://www.pc 104.org 


Faible encombrement mais couteux 


DIL 


Cartes mere 


SSV 


http://www. dilnetpc. com 




liCsimm 


Carte mere 


Lineo 


http://www. uclinux. com 


Pour u.Clinux, tres faible encombrement 
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En resume 

L' architecture PC est aujourd'hui un choix interessant pour un systeme Linux embarque, 
en particulier pour la phase de maquettage. D'autres choix comme le PowerPC sont ega- 
lement tres viables. Une grande serie sur un systeme plus enfoui peut justifier l'utilisation 
d' architectures telles que le StrongARM. 

Le portage uClinux peut fonctionner sur des processeurs sans MMU (en general, des 
micro-controleurs). Ces processeurs generent des couts de mise en oeuvre inferieurs mais 
induisent des contraintes de fonctionnement (dues a la protection de la memoire). 

II existe aujourd'hui de nombreux peripheriques « disque flash », compatibles Linux. 

Les formats PC/104, cartes DIL et uCsimm sont repandus dans le monde Linux embar- 
que et Ton trouve des kits de developpement qui facilitent leur integration. 



Deuxieme partie 



Methodologie de 
creation d'un systeme 
Linux embarque 



Apres une presentation detaillee des principaux elements du 
noyau Linux, nous decrirons une methode permettant de realiser 
une version embarquee de Linux a partir de composants d'une 
distribution classique. 

Nous traiterons ensuite la mise en place et ['optimisation de 
composants comme la couche reseau ou bien Ies differentes inter- 
faces graphiques disponibles dans un environnement reduit. 
Les differentes methodes de debogage adaptees a 1'environnement 
embarque seront egalement detaillees. Enfin, nous aborderons 
quelques techniques particulieres mais essentielles comme la 
gestion des memoires « flash » et des systemes de demarrage. 

Plusieurs chapitres seront consacres a des versions speciales 
de Linux comme les extensions temps-reel (RTLinux et RTAI) 
et la version pour micro-controleur uCIinux. Et pour finir, un 
chapitre sera dedie a I'utilisation de 1'environnement Open Source 
PeeWeeLinux. 



4 



Structure de Linux 



Ce chapitre decrit les elements principaux de la structure de Linux. 

Les tests et manipulations decrits dans ce chapitre pourront etre realises sur un systeme 
installe avec une distribution classique. A quelques exceptions pres, la structure du sys- 
teme est calquee sur les autres systemes Unix libres ou proprietaries a savoir : 

• un noyau ou kernel realisant les fonctions essentielles comme la gestion des taches et 
de la memoire, ainsi que l'interfacage entre le materiel et les applicatifs grace entre 
autres aux pilotes de peripheriques ou en anglais device drivers ; 

• une bibliotheque principale appelee libc ou glibc (GNU libc) sous Linux et contenant 
les fonctions de base utilisees par les applicatifs ; 

• les applicatifs eux-memes, appeles egalement commandes, soit livres en standard avec 
le systeme ou bien developpes pour des besoins specifiques. 



Remarques 

Cet ouvrage etant destine specifiquement a I'utilisation de Linux dans des applications embarquees, notre inten- 
tion n'est pas de nous livrer a une etude approfondie des differents composants du systeme mais plutot de 
presenter les elements indispensables a la realisation d'un systeme embarque. 

Les exemples presentes dans ce chapitre sont bases sur le noyau 2.4 mais les concepts sont egalement vrais 
pour le noyau 2.6. En cas de difference notable entre les deux versions, celle-ci sera explicitee. 



La structure du systeme est de forme concentrique comme decrit dans la figure 4-1 
ci-apres. 
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Figure 4-1 

Structure du systeme. 




A ces elements standards il faut ajouter un programme de demarrage ou bootstrap 
comme LILO (Linux LOader). A la difference des autres composants du systeme, le pro- 
gramme de demarrage ou chargeur est tres dependant du materiel utilise. Quelques ele- 
ments de la configuration de LILO sont explicites dans ce chapitre. 

Le schema de demarrage d'un systeme Linux est relativement simple et on peut le 
decomposer comme suit : 

1. Chargement du systeme par LILO ou un programme equivalent, comme GRUB. 

2. Chargement du noyau Linux. Le chargement s'accompagne de 1' initialisation des 
peripheriques materiels indispensables au demarrage, et done au chargement des pilo- 
tes de peripheriques associes. Le noyau Linux tente egalement de charger sa partition 
principale ou root partition sur laquelle il ira chercher les elements necessaires a la 
suite du lancement du systeme. 

3. Lorsque le noyau Linux est charge, il execute un programme d'initialisation qui, par 
defaut, correspond a la commande /sbin/init. Cependant, on peut indiquer facile - 
ment au noyau de passer la main a un autre programme. 

4. Dans le cas de l'utilisation du programme i ni t standard, ce dernier explore le fichier 
de configuration /etc/inittab qui contient le chemin d'acces a un script de demar- 
rage, comme ceci : 

I# System initialization (runs when system boots), 
si :S:sysinit:/etc/rc.d/rc.d/rc.sysinit 

Le script en question poursuit 1' initialisation du systeme. 
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Le noyau Linux 

Le noyau est 1' element principal du systeme, et ce pour plusieurs raisons. La premiere 
raison est historique puisque ce noyau fut initialement concu par Linus Torvalds, createur 
du systeme Linux, le reste du systeme etant constitue de composants provenant en majo- 
rite du projet GNU de Richard Stallman. L autre raison est technique et tient en 1' occur- 
rence a la structure monolithique du noyau qui en fait 1' interface unique entre le systeme 
et le materiel dans la quasi-totalite des cas de figure. 

Structure globale du noyau 

Dans le cas de Linux, le noyau est un fichier executable, monolithique ou presque, charge 
d' assurer les fonctions essentielles du systeme comme la gestion des laches, ou schedu- 
ling, la gestion de la memoire et le pilotage des peripheriques que ceux-ci soient reelle- 
ment des peripheriques materiels ou bien qu'ils soient des peripheriques virtuels comme 
les systemes de fichiers que nous decrirons plus en detail dans la suite de l'ouvrage. 

Dans une distribution Linux classique, le noyau est physiquement represents par un 
fichier localise sur le repertoire /boot : 

I# Is -1 /boot/vmlinuz-2.4.7-10 
-rw-r— r-- 1 root root 802068 sep 6 2001 /boot/vmlinuz-2.4.7-10 

Le nom du noyau est libre mais il est generalement suffixe en fonction de la version du 
noyau, ici 2.4.7 et de V extra-version choisie par celui qui a genere ce noyau, soit 10 dans 
le cas present. On peut avoir de meme : 

7 14:27 /boot/bzImage-2.4.14 
28 16:51 /boot/bzImage-2.4.16_plockb 
27 17:06 /boot/bzImage-2.4. 16_rtsched 

Nous verrons plus tard que 1' extra-version est definie dans le fichier Ma kef i 1 e de l'arbo- 
rescence des sources du noyau. 

Le noyau Linux utilise egalement un fichier nomme System. map qui contient des infor- 
mations sur des adresses internes du noyau. Ces informations sont utiles a la gestion des 
modules decrits ci-apres. Le fichier System. map est egalement present sur le repertoire 
/boot. En toute rigueur, il est lie a la version complete du noyau genere, y compris 
1' extra- version, car il est genere lors de la compilation du noyau. 

Les modules chargeables du noyau 

Dans les cas d' applications classiques de Linux, le noyau utilise le plus souvent des 
modules qui peuvent etre dynamiquement charges et decharges en fonction des besoins 
du systeme. Ces modules peuvent etre des pilotes de peripheriques materiels, comme des 
cartes d' extension, ou bien lies a un support generique de plus haut niveau comme le sup- 
port SCSI. Lutilisation des modules permet d'optimiser la memoire du systeme a un ins- 
tant donne car un pilote non utilise pourra etre decharge, liberant ainsi sa memoire. 



§ Is -1 /boot/bzlmage* 






-rw-r--r-- 1 root 


root 


952696 fev 


-rw-r--r-- 1 root 


root 


761341 mai 


-rw-r--r-- 1 root 


root 


767760 mai 
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De meme, l'utilisation des modules permettra d'ajouter dynamiquement des peripheriques 
sans redemarrer le systeme. 

Dans le cas d'un noyau embarque, on pourra cependant se poser la question quant a l'utili- 
sation des modules sachant que ceux-ci necessitent la validation d'options specifiques 
lors de la compilation du noyau, ce qui augmente legerement sa taille. De meme, la 
hierarchie des modules necessite la mise en place du repertoire /lib/modules, ce qui 
augmente le nombre de fichiers, la complexite du systeme et aussi legerement l'espace 
occupe par ce dernier. 

Le choix de l'utilisation ou non des modules sera laisse a la charge de l'integrateur du 
systeme en fonction de ses besoins. Differents cas de figure seront envisages dans les 
chapitres concernant la reduction du systeme. 



# Is -1 /ll 


b/modules 










total 52 












drwxr-xr-x 


4 root 


root 


4096 mai 


27 


16:45 2.4.18-rtsched 


drwxr-xr-x 


5 root 


root 


4096 mai 


23 


11:44 2.4.4-rtl 


drwxr-xr-x 


4 root 


root 


4096 fev 


13 


17:08 2.4.7-10 


drwxr-xr-x 


4 root 


root 


4096 nov 


25 


2001 2.4.9-13 


drwxr-xr-x 


4 root 


root 


4096 fev 


7 


14:05 2.4.9-21 



A chaque sous-repertoire correspond une version du noyau. Dans le cas present, les 
modules utilises par le noyau seront localises dans le repertoire 2.4.7-10. 



# Is -1 /ll 


b/modules/2 


4.7-10/ 


total 228 








1 rwxrwxrwx 


1 


root 


root 


drwxr-xr-x 


7 


root 


root 


-rw-r--r-- 


1 


root 


root 


-rw-r--r-- 


1 


root 


root 


-rw-r--r-- 


1 


root 


root 


-rw-r--r-- 


1 


root 


root 


-rw-r--r-- 


1 


root 


root 


-rw-r--r-- 


1 


root 


root 


-rw-r--r-- 


1 


root 


root 


drwxr-xr-x 


2 


root 


root 



31 nov 1 2001 build -> ../../. ./usr/src/ 
* linux-2.4.7-10 

4096 nov 1 2001 kernel 

82111 mar 25 17:40 modules. dep 

31 mar 25 17:40 modules. generic_string 

73 mar 25 17:40 modules. ieeel394map 

7673 mar 25 17:40 modules. isapnpmap 

29 mar 25 17:40 modules. parportmap 

45571 mar 25 17:40 modules. pcimap 

59973 mar 25 17:40 modules. usbmap 

4096 nov 1 2001 pcmcia 



Les modules sont repartis dans des sous-repertoires selon une classification fonctionnelle. 
La liste ci-apres permet de visualiser les modules correspondant a des pilotes reseau : 



# Is -1 /lib/modules/2.4.7-10/kernel/drivers/net 
total 2348 



head 



-rw-r- 


-r-- 


1 


root 


root 


9852 sep 


6 


2001 3c501.o 


-rw-r- 


-r-- 


1 


root 


root 


8912 sep 


6 


2001 3c503.o 


-rw-r- 


-r-- 


1 


root 


root 


24996 sep 


6 


2001 3c505.o 


-rw-r- 


-r-- 


1 


root 


root 


10304 sep 


6 


2001 3c507.o 


-rw-r- 


-r-- 


1 


root 


root 


13652 sep 


6 


2001 3c509.o 


-rw-r- 


-r-- 


1 


root 


root 


22568 sep 


6 


2001 3c515.o 


-rw-r- 


-r-- 


1 


root 


root 


41920 sep 


6 


2001 3c59x.o 
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I-rw-r--r-- 1 root root 22072 sep 6 2001 8139too.o 

-rw-r--r— 1 root root 22160 sep 6 2001 82596.0 

Le fichier modul es .dep contient les dependances entre les modules sous la forme d'une 
simple liste contenant une definition de dependance par ligne. Cette liste est generee au 
demarrage du systeme par la commande depmod -a. 

On doit egalement utiliser cette commande chaque fois que Ton ajoute un nouveau 
module a 1' arborescence des modules. Un extrait de la liste est presente ci-apres : 



/lib/modules/2.4.7-10/kernel/fs/vfat/vfat.o: 
/lib/modules/2.4.7-10/kernel/fs/fat/fat.o 



I 

La ligne ci-apres montre que le module vfat.o necessite la presence du module f at.o. 

Bien que les modules soient normalement charges de maniere automatique par le sys- 
teme, nous allons decrire en quelques lignes les principales commandes de manipulation 
des modules, et ce afin de donner un bon apercu des operations possibles sur les modules. 

Remarque 

Les modules sont manipules grace a un paquetage nomme modutils. En cas d'utilisation du noyau 2.6, il est 
necessaire d'utiliser une version recente du paquetage (module-init-tools-3.0 ou superieur) disponible en tele- 
chargement avec les sources du noyau. Ces dernieres versions sont compatibles 2.4 et 2.6. 

On peut forcer le chargement d'un module en utilisant la commande insmod. Prenons 
l'exemple d'un module hello.o sans dependance avec aucun autre module. On peut 
charger ce module au moyen de la commande : 

# insmod hello.o 

On peut aussi ajouter ce module a 1' arborescence des modules standards en effectuant : 

I# cp hello.o 
/I ib/modules/2.4.7-10/kernel /drivers/char/1 ib/modules/2.4.7-10/kernel/driver/char 
# depmod -a 



puis charger ce module avec la commande : 

I 



# insmod hello 

Using /l ib/modules 72.4.7 -10/ kernel /drivers/char/hel lo.o 



Notez qu'il est necessaire d'etre super-utilisateur pour charger un module, et, egalement, 
que dans le cas ou le module est installe dans 1' arborescence, on ne specifie pas le suffixe. 
La trace du chargement effectif du module est visible dans le fichier des messages du 
noyau. On peut egalement verifier sa presence en utilisant la commande 1 smod : 

# dmesg | tail -1 
Hel lo world! 

# lsmod 

Module Size Used by 

hello 292 (unused) 
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Lors du chargement du module, il est possible de specifier des parametres par la ligne de 
commande : 

| insmod bttv card=39 

Les parametres peuvent etre specifies dans le fichier /etc/modul es . conf afin d'etre utili- 
ses automatiquement lors du chargement du module. Dans le cas du noyau 2-6, on utilise 
le fichier /etc/conf .modules : 

I alias ethO 3c59x 
options i 2c-al go-bi t bit_test=l 
options bttv card=39 

La commande alias permet de faire une association automatique entre un nom de module 
generique et le nom de module effectif. Dans le cas present, le module 3c59x sera charge 
lors de 1' initialisation de 1' interface reseau Ethernet qui necessite le module generique 
ethO. Apres chaque modification du fichier, on doit utiliser la commande /sbi n/depmod -a. 

Pour decharger le module, on utilise la commande rmmod : 

I§ rmmod hello 
# dmesg | tail -1 
Goodbye cruel world! 

Dans le cas de modules dependant d'autres modules, on ne peut cependant pas utiliser 
insmod. Reprenons l'exemple du module vf at qui necessite la presence du module fat : 

# insmod vfat 

Using /I ib/modules/2.4.7-10/kernel /fs/vfat/vfat.o 

/l ib/modules/2.4.7-10/kernel /fs/vfat/vfat.o: unresolved symbol 

*• fat_read_super_R12852204 

/l ib/modules/2. 4. 7-10/kernel /fs/vfat/vfat.o: unresolved symbol 

*• fat_mark_buffer_di rty_R2f 222951 

Dans ce cas-la, on devra utiliser la commande modprobe qui chargera le module, ainsi que 
tous les modules dependants : 



# modprobe vfat 








# lsmod | grep fat 








vfat 


9540 





(unused) 


fat 


30688 





[vfat] 



De ce fait, il n'est pas possible de decharger le module fat car celui-ci est maintenant uti- 
lise par le module vfat : 



# rmmod fat 

fat: Peripherique ou ressource occupe 



On devra tout d'abord decharger vfat, puis fat 

I 



# rmmod vfat 
§ rmmod fat 



Structure de Linux 

Chapitre 4 

On se rend vite compte que ces manipulations sont fastidieuses, parfois inextricables si le 
nombre de dependances entre les modules devient important. C'est la raison pour 
laquelle le noyau Linux permet d'utiliser des systemes automatiques de chargement et 
dechargement des modules en fonction des besoins. II existe deux systemes equivalents 
pour effectuer cette tache. 

Le demon kernel d est un programme standard qui tourne dans l'espace utilisateur et non 
dans l'espace du noyau. II utilise un systeme d'IPC System V arm de communiquer avec 
le noyau et determiner en temps reel les modules a charger lorsque 1' utilisateur desire 
activer un nouveau peripherique comme un systeme de fichier, un peripherique SCSI ou 
une carte son. Les IPC furent introduits dans Unix System V comme un ensemble de 
facilites de communications entre divers processus. On peut done utiliser des fonction- 
nalites de semaphores, des zones de memoire partagee (shared memory) ou des riles de 
messages. 

Le demon kernel d se charge d'effectuer le chargement des modules necessaires en effec- 
tuant les actions equivalentes a la commande modprobe. De meme, lorsque le module 
devient inutile parce que le peripherique n'est plus utilise, kernel d effectue automatique- 
ment une action equivalente a la commande rmmod. L indication de la part d' utilisation 
d'un module est effectuee par le noyau en positionnant le drapeau d'etat AUTOCLEAN 
sur le module. Ce drapeau est visible lors de 1' utilisation de la commande 1 smod : 



# 1 smod 






Module 


Size 


Used by 


hello 


324 


(unused) 


nfsd 


162752 


8 (autoclean) 



Le delai de dechargement du module par kernel d est de facon typique de 60 secondes. 

Pour diverses raisons, le demon kernel d a cependant ete remplace par kmod, qui est un 
thread au niveau noyau Linux et qui fonctionne done dans l'espace noyau et non dans 
l'espace utilisateur. Les raisons du changement evoquees par les developpeurs du noyau 
sont les suivantes : 

• le demon kernel d se servait des IPC System V dont l'utilisation n'est pas recomman- 
dee, surtout en cas de dialogue avec le noyau ; 

• kmod et kernel d apportent quasiment les meme fonctionnalites, en l'occurrence 
l'appel de modprobe ; 

• la suppression du code inherent a kernel d dans le noyau a permis de gagner un nom- 
bre de lignes de code non negligeable ; 

• vu que kmod est execute dans l'espace du noyau et non dans l'espace utilisateur, il uti- 
lise le mecanisme standard des traces d'erreurs du noyau Linux. 

kmod et kernel d se differencient en ceci que le dechargement automatique du module est 
absent dans le cas de kmod. Le dechargement des modules marques du drapeau autoclean 
devra etre programme par une ligne crontab du super-utilisateur root : 

0-59/5 * * * * /sbin/rmmod -a 
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Le systeme de fichier/proc 

Pour communiquer avec l'espace utilisateur, le noyau Linux utilise un concept emprunte a 
Unix System V : le systeme de fichier /proc. A la difference des systemes de fichiers clas- 
siques qui sont associes a des peripheriques reels, le systeme de fichier /proc est virtuel. Sa 
structure de systeme de fichier en fait une representation facile pour manipuler des parame- 
tres du noyau Linux. On peut en effet utiliser les commandes standards de manipulation des 
fichiers classiques, ainsi que la redirection des entrees/sorties tres utilisee sous Linux. 

En particulier, la commande lsmod de lecture des modules charges n'est en fait qu'un 
raccourci pour la visualisation du fichier virtuel /proc/modul es : 



# cat /proc/modul es 








hello 


324 





(unused) 


nfsd 


162752 


8 


(autoclean) 


lockd 


44080 


1 


(autoclean) 



[nfsd] 

De meme, on peut visualiser les parametres standards du systeme comme la memoire 
disponible au moyen de /proc/memi nf o, la version du noyau avec /proc/versi on, le type 
de processeur utilise avec /proc/cpuinfo, ou les systemes de fichiers supportes par le 
noyau avec /proc/filesystems. Cette liste n'est, bien entendu, pas exhaustive car un 
pilote de peripherique peut ajouter dynamiquement des fichiers et repertoires a /proc lors 
du chargement du module associe. 

De meme, les valeurs numeriques presentes dans /proc representent les zones d'informa- 
tion des processus courant, chaque valeur correspondant au PID (Processus IDentifier) 
du processus en question. Ces sous-repertoires contiennent les informations propres au 
processus en question : 

# Is -1 /proc/25832 
total 

-r--r--r-- 1 root root 

-r--r--r-- 1 root root 

1 rwx 1 root root 

-r 1 root root 

1 rwx 1 root root 

dr-x 2 root root 

pr--r--r-- 1 root root 

-rw 1 root root 

1 rwx 1 root root 

-r--r--r-- 1 root root 

-r--r--r-- 1 root root 

-r--r--r-- 1 root root 

Par exemple, le fichier status contient des informations sur l'efat du processus en ques- 
tion : 

# cat /proc/25832/status 
Name: httpd 
State: S (sleeping) 
Pid: 25832 
PPid: 2173 



oct 


21 


23:42 


cmdl ine 


oct 


21 


23:42 


cpu 


oct 


21 


23:42 


cwd -> / 


oct 


21 


23:42 


environ 


oct 


21 


23:42 


exe -> /usr/sbin/httpd 


oct 


21 


23:42 


fd 


oct 


21 


23:42 


maps 


oct 


21 


23:42 


mem 


oct 


21 


23:42 


root -> / 


oct 


21 


23:42 


stat 


oct 


21 


23:42 


statm 


oct 


21 


23:42 


status 
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Le systeme de fichier /proc est egalement utilisable en ecriture, ce qui permet de 
modifier dynamiquement le comportement du noyau Linux sans aucune compilation. 
Un exemple classique est la validation d' option comme par le transfert de paquets IP 
(IP forwarding). On peut connaitre la valeur de l'option d' IP forwarding en faisant : 

It cat /proc/sys/net/ipv4/ip_forward 
1 
Le systeme retourne la valeur 1, ce qui signifie que V IP forwarding est valide. On peut 
l'inhiber en faisant simplement : 

# echo > /proc/sys/net/ipv4/ip_forward 

Qui a dit que Linux etait complique ? 

Une description complete du pseudo-systeme de fichiers /proc est disponible dans le 
repertoire de documentation des sources du noyau Linux, soit : 

/usr/src/1 inux/Documentation/proc.txt 
pour le noyau 2.2, et 

/usr/src/1 i nux- 2. 4/Documentation/filesy steins /proc. txt 
pour les noyaux 2.4 et 2.6. 

Compilation du noyau 

Les distributions classiques fournissent des noyaux binaires pre-compiles, soit sous 
forme d' archives RPM dans le cas des distributions Red Hat, Mandriva et SuSE, soit sous 
forme d'archives DEB dans le cas de la distribution. DEBIAN. 

L utilisation de Linux dans un environnement industriel embarque obligera cependant a 
adapter le noyau a 1' environnement materiel, soit en partie l'objet meme de cet ouvrage ! 

Notre intention dans cette section est de fournir les elements necessaires a l'obtention de 
1' archive officielle du noyau, a 1' extraction de celle-ci, la configuration de ce noyau, puis 
sa compilation et son installation. Ces elements seront donnes sous un angle general sans 
consideration de reduction de la taille du noyau. Les possibilites de reduction seront 
explicitees dans les chapitres suivants. 

Comme dans tous les developpements Open Source, la distribution officielle du noyau 
Linux est fournie sous forme d' archive au format tar compressee au format gzip ou 
bzip2. Ces archives sont disponibles aupres du serveur ftp://ftp.kernel.org ou l'un de ses 
miroirs tel le site ftp://ftp.free.fr. 

Les sources du noyau Linux sont egalement fournies par les distributions classiques sous 
forme d'archives RPM ou DEB. Nous devons insister ici sur le fait que 1' archive du 
noyau fournie par exemple sur le CD-Rom Red Hat n'est pas identique a celle que vous 
trouverez sur le site ftp://ftp.kernel.org. 

La licence GPL permet en effet a l'editeur d'apporter des modifications aux sources du noyau 
a condition que ces modifications soient egalement fournies en sources sur le CD-Rom. 
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De plus, il peut arriver que certains pilotes de peripheriques ne soient par fournis sur 
P archive officielle du noyau Linux, etant considered par Linus Torvalds comme pas assez 
aboutis, bien qu'ils soient presents sur le CD-Rom d'un editeur souvent en raison de la 
pression commerciale. 

Attention 

Dans la suite de I'ouvrage, et ce afin de ne pas entrer dans le jeu de la guerre des distributions, nous ferons 
toujours reference au noyau Linux officiel et non a ceux fournis par les editeurs. 



Nous donnons ci-apres la trace du dialogue ftp avec le site ftp://ftp.free.fr afin de recuperer 
les sources du noyau officiel. Le client ftp utilise est Pexcellent ncftp disponible dans 
toutes les bonnes distributions. 



$ ncftp ftp. 


free.fr 
















NcFTP 3.1.5 


(Oct 13, 


2002) by M 


ke Gleason 


(nc 


; tp(a 


ncftp 


com) . 


Connecting t 


o 213.228 


.0. 


141... 












Welcome to P 


roXc 


d FTP 


server 












Logging in. . 




















Login successfu" 


. 
















Logged in to 


ftp. free 


.fr 














ncftp / > cd 


mirrors/ftp 


.kernel 


org/1 inux/kernel 






Directory successful! 


/ c 


hanged. 












ncftp ...ernel.org/linux 


/kernel 


> dir 










-r--r--r-- 


1 


1000 




1000 


18458 


mar 


13 


1994 


COPYING 


-r--r--r-- 


1 


1000 




1000 


36981 


sep 


16 


1996 


CREDITS 


drwxr-sr-x 


5 


1000 




1000 


4096 


nov 


24 


2001 


crypto 


drwxr-sr-x 


4 


1000 




1000 


4096 


mar 


20 


2003 


Historic 


drwxr-sr-x 


61 


1000 




1000 


4096 


avr 


8 


23:07 


people 


drwxr-sr-x 


6 


1000 




1000 


4096 


mar 


13 


2003 


ports 


drwxr-sr-x 


3 


1000 




1000 


4096 


sep 


16 


2000 


projects 


-r--r--r-- 


1 


1000 




1000 


12056 


sep 


16 


1996 


README 


drwxr-sr-x 


2 


1000 




1000 


4096 


avr 


14 


2000 


Sil lySounds 


drwxr-sr-x 


3 


1000 




1000 


4096 


fev 


14 


2002 


testing 


drwxr-sr-x 


2 


1000 




1000 


4096 


mar 


20 


2003 


uemacs 


drwxr-sr-x 


2 


1000 




1000 


4096 


mar 


20 


2003 


vl.O 


drwxr-sr-x 


2 


1000 




1000 


20480 


mar 


20 


2003 


vl.l 


drwxr-sr-x 


2 


1000 




1000 


8192 


mar 


20 


2003 


vl.2 


drwxr-sr-x 


2 


1000 




1000 


36864 


mar 


20 


2003 


vl.3 


drwxr-sr-x 


3 


1000 




1000 


12288 


fev 


8 


2004 


v2.0 


drwxr-sr-x 


2 


1000 




1000 


45056 


mar 


20 


2003 


v2.1 


drwxr-sr-x 


3 


1000 




1000 


8192 


mar 


24 


2004 


v2.2 


drwxr-sr-x 


2 


1000 




1000 


20480 


mar 


20 


2003 


v2.3 


drwxr-sr-x 


5 


1000 




1000 


12288 


avr 


4 


01:50 


v2.4 


drwxr-sr-x 


4 


1000 




1000 


28672 


j ui 


14 


2003 


v2.5 


drwxr-sr-x 


6 


1000 




1000 


8192 


avr 


7 


19:30 


v2.6 



Ce miroir conserve la trace de toutes les versions du noyau Linux depuis la 1.0. Nous 
rappelons que la numerotation des versions du noyau suit les regies suivantes : 

• Le noyau est identifie par un triplet version.revision.patch, exemple 2.4.13. 
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• Les revisions paires identifient des noyaux stables. En route rigueur, ce sont les seuls 
qu'il faut utiliser dans le cas de produits industriels. 

• Les corrections (ou patch) sur un noyau stable n'incluent que des corrections de 
bogues mais pas de nouvelles fonctionnalites. 

• Les revisions impaires sont des noyaux de developpement. La frequence de diffusion 
de ces noyaux peut etre tres elevee, parfois un par semaine ou plus. Certaines correc- 
tions peuvent apporter de nouvelles fonctionnalites. Certains noyaux de developpe- 
ment sont tres stables mais leur utilisation n'est absolument pas recommandee pour 
des applications industrielles. 

• Le passage d'une version de developpement a une version stable suppose un gel du 
code ou code-freeze decide par Linus lui-meme. Ce passage peut connaitre des phases 
intermediaires comme les pre -versions stables, exemple 2.3.99-prel a pre9. Cela tient 
a ce que la complexite du noyau va croissant au cours du temps et que la diffusion 
d'une premiere version stable est une operation de plus en plus delicate. 

Si nous souhaitons recuperer la derniere version du noyau 2.4, nous devons proceder aux 
actions suivantes : 

Incftp ...ernel.org/linux/kernel > cd v2.4 
ncftp org/linux/kernel/v2.4 > Is LATEST* 
LATEST-IS-2.4.13 

La deuxieme ligne permet de connaitre la derniere version du noyau, ici en 1' occurrence 
2.4.13. II suffit ensuite de recuperer l'archive soit au format gzip, soit au format bzipl. 
Ce dernier format est recommande car il permet de reduire la taille de l'archive, et done 
le temps de telechargement. Ici, Ton voit que Ton gagne 5 Mo sur la taille de l'archive : 

ncftp . . . .org/1 inux/kernel/v2.4 > dir 1 inux-2.4.13* 

23111925 oct 24 05:28 1 inux-2.4.13. tar. bz2 

248 oct 24 05:28 1 inux-2.4.13. tar. bz2. sign 
28561727 oct 24 05:28 1 inux-2.4.13. tar. gz 

248 oct 24 05:28 1 inux-2.4.13. tar. gz. sign 
get linux-2.4.13.tar.bz2 
linux-2.4.13.tar.bz2: 22,04 MB 44.23 kB/s 

ncftp . . . .org/1 inux/kernel /v2.4 > 

Apres recuperation de l'archive, il faut la decompresser dans le repertoire adequat. Ce 
repertoire est generalement /usr/sre. II se peut que vous disposiez deja de l'arbores- 
cence des sources grace a votre distribution Linux, soit du fait de 1' installation prealable 
d'un noyau 2.4 : 



11 oct 27 22:02 linux-2.4 -> linux-2.4.2 
4096 oct 22 14:42 linux-2.4.2 



11 oct 27 22:02 linux -> linux-2.4.2 
4096 oct 22 14:42 linux-2.2.19 



-rw-r- 


-r- 


1 daemon 


daemon 


-rw-r- 


-r- 


1 daemon 


daemon 


-rw-r- 


-r- 


1 daemon 


daemon 


-rw-r- 


-r- 


1 daemon 


daemon 


ncftp 




.org/1 inux/ke 


rnel/v2. 



# cd /usr/src 






# Is -Id linux* 






1 rwxrwxrwx 1 


root 


root 


drwxr-xr-x 16 


root 


root 


bien : 






# Is -Id linux* 






1 rwxrwxrwx 1 


root 


root 


drwxr-xr-x 16 


root 


root 
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Si Ton regarde 1' archive telechargee, on remarque que celle-ci est construite a partir du 
repertoire /usr/src : 

# tar tjvf linux-2.4.13.tar.bz2 

drwxr-xr-x torvalds/eng 2001-10-24 07:21:20 linux/ 

-rw-r--r-- torvalds/eng 16909 2001-10-24 07:21:20 1 inux/Makefile 
drwxr-xr-x torvalds/eng 2001-10-24 07:17:55 linux/fs/ 

-rw-r--r-- torvalds/eng 9564 2001-09-14 01:04:43 linux/fs/stat.c 

-rw-r--r-- torvalds/eng 2292 2001-10-05 00:13:18 1 inux/fs/Makefile 

-rw-r--r-- torvalds/eng 8859 2001-08-05 22:12:41 1 inux/fs/read_write.c 

On notera l'option «j » de la commande tir qui permet d'utiliser le decompresseur 
bzi p2 avant d'extraire 1' archive. 

S'il existe deja un repertoire /usr/src/1 inux, il faudra done le renommer si Ton ne veut 
pas l'ecraser avec les nchiers de la nouvelle archive. Cette etape n'est plus necessaire 
dans le cas des dernieres versions du noyau 2.4 (a partir de la 2.4.20) et du noyau 2.6 car 
le repertoire cree par l'extraction du noyau est - enfin - indexe sur la version du noyau. 

Dans notre cas, il suffit d'extraire l'archive dans /usr/src : 

§ tar xjvf /root/1 inux-2.4. 13.tar.bz2 | more 

1 inux/ 

1 inux/Makefile 

1 inux/fs/ 

1 inux/fs/stat.c 

1 inux/fs/Makefile 

1 inux/fs/read_write.c 

1 inux/fs/block_dev.c 

# 

ce qui donne sur le repertoire : 

# Is -Id linux* 

drwxr-xr-x 14 1046 101 4096 oct 27 22:18 linux 

lrwxrwxrwx 1 root root 11 oct 27 22:02 linux-2.4 -> linux-2.4.2 

drwxr-xr-x 16 root root 4096 oct 22 14:42 linux-2.4.2 

puis de renommer le repertoire linux avec la version correcte, soit 2.4.13, et finalement 
de positionner le lien symbolique sur cette version, ce qui donne : 

# mv 1 inux 1 inux-2.4. 13 
[root@local host src]# rm -f linux-2.4 
[root@local host src]# In -s linux-2.4. 13 linux-2.4 
[root@localhost src]# Is -Id linux-2.4* 

lrwxrwxrwx 1 root root 12 oct 27 22:20 linux-2.4 -> linux-2.4. 13 

drwxr-xr-x 14 1046 101 4096 oct 27 22:18 linux-2.4. 13 

drwxr-xr-x 16 root root 4096 oct 27 22:20 linux-2.4.2 

Cette methode permet de conserver les differentes arborescences des sources du noyau et 
de passer de Tune a l'autre en positionnant un simple lien symbolique. 
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# cd 1 inux-2 


.4 






# Is -1 








total 240 








drwxr-xr-x 


17 


1046 


101 


-rw-r— r— 


1 


1046 


101 


-rw-r— r— 


1 


1046 


101 


drwxr-xr-x 


28 


1046 


101 


drwxr-xr-x 


38 


1046 


101 


drwxr-xr-x 


41 


1046 


101 


drwxr-xr-x 


24 


1046 


101 


drwxr-xr-x 


2 


1046 


101 


drwxr-xr-x 


2 


1046 


101 


drwxr-xr-x 


2 


1046 


101 


drwxr-xr-x 


2 


1046 


101 


-rw-r— r— 


1 


1046 


101 


-rw-r— r— 


1 


1046 


101 


drwxr-xr-x 


2 


1046 


101 


drwxr-xr-x 


27 


1046 


101 


-rw-r— r— 


1 


1046 


101 


-rw-r— r— 


1 


1046 


101 


-rw-r— r— 


1 


1046 


101 


drwxr-xr-x 


5 


1046 


101 



On peut alors se positionner dans le repertoire arm de regarder la structure globale de 
l'arborescence : 



4096 fev 13 2001 arch 

18689 oct 10 00:00 COPYING 

77588 oct 21 19:20 CREDITS 

4096 oct 27 22:18 Documentation 

4096 oct 27 22:18 drivers 

4096 oct 27 22:17 fs 

4096 oct 24 07:18 include 

4096 oct 27 22:17 init 

4096 oct 27 22:17 ipc 

4096 oct 27 22:17 kernel 

4096 oct 27 22:17 lib 

38094 oct 22 17:37 MAINTAINERS 

16909 oct 24 07:21 Makefile 

4096 oct 27 22:17 mm 

4096 oct 27 22:17 net 

14242 oct 5 21:10 README 

2815 avr 6 2001 REPORTING-BUGS 

8884 mar 7 2001 Rules. make 

4096 oct 27 22:18 scripts 

Dans le cas du noyau 2.6, la liste des repertoires est tres similaire : 

# cd /usr/src/1 inux-2. 6. 10 

# Is -1 
total 408 

drwxrwxr-x 24 root root 4096 dec 24 22:33 arch 

-rw-r--r-- 1 root root 18691 dec 24 22:34 COPYING 

-rw-r--r— 1 root root 88167 dec 24 22:35 CREDITS 

drwxrwxr-x 2 root root 4096 avr 6 07:55 crypto 

drwxrwxr-x 46 root root 4096 dec 24 22:35 Documentation 

drwxrwxr-x 46 root root 4096 avr 6 07:55 drivers 

drwxrwxr-x 54 root root 4096 avr 6 07:55 fs 

drwxrwxr-x 37 root root 4096 fev 11 09:26 include 

drwxrwxr-x 2 root root 4096 avr 6 07:55 init 

drwxrwxr-x 2 root root 4096 avr 6 07:55 ipc 

drwxrwxr-x 4 root root 4096 avr 6 07:55 kernel 

drwxrwxr-x 5 root root 4096 avr 6 07:55 lib 

-rw-r— r— 1 root root 55119 dec 24 22:35 MAINTAINERS 

-rw-r--r— 1 root root 43257 fev 11 09:26 Makefile 

drwxrwxr-x 2 root root 4096 avr 6 07:55 mm 

-rw-r--r-- 1 root root 104306 fev 11 09:44 Module. symvers 

drwxrwxr-x 32 root root 4096 avr 6 07:55 net 

-rw-r--r— 1 root root 13970 dec 24 22:35 README 

-rw-r— r— 1 root root 2815 dec 24 22:34 REPORTING-BUGS 

drwxrwxr-x 9 root root 4096 avr 6 07:55 scripts 

drwxrwxr-x 4 root root 4096 avr 6 07:55 security 

drwxrwxr-x 15 root root 4096 avr 6 07:55 sound 

drwxrwxr-x 2 root root 4096 avr 6 07:55 usr 
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Nous pouvons donner une breve description des fichiers et sous-repertoires de l'arbo- 
rescence du noyau. La description de certains sous-repertoires sera approfondie si neces- 
saire dans la suite de l'ouvrage. 

irch contient le code source specifique des architectures materielles comme x86, ppc, 
alpha ou m68k. 

Documentation contient des fichiers de documentation au format. 

drivers contient 1' arborescence des divers pilotes de peripheriques. 

f s contient le code source des differents systemes de fichiers, ou file-systems supportes 
par le noyau. Nous pouvons citer par exemple ext2, vfat ou iso9660. 

incl ude contient les fichiers d'en-tete C necessaires a la compilation du noyau mais 
egalement au developpement d' applications. 

init contient le fichier principal main.c, contenant la fonction principale main( ), du 
noyau Linux. 

i pc contient le code source de la version des IPC System V du noyau Linux. 

kernel contient le code source des fonctions majeures du noyau comme la gestion des 
taches ou des processus. 

mm contient les fonctions de gestion de la memoire ou memory-management. 

net contient le code source des differents protocoles reseau supportes par le noyau 
Linux. Nous pouvons citer ip\4, ipv6 ou x25. 

scri pts contient le code source des outils de configuration du noyau. 

Makefile et Rules. make sont les fichiers utilises par la commande make lors de la 
compilation du noyau. 

sound contient dans le cas du noyau 2.6 les pilotes ALSA (Advanced Linux Sound 
Archicture) desormais integres en standard aux sources du noyau. 

La generation d'un nouveau noyau passe par les phases suivantes : 

la configuration des options du noyau ; 

la generation des dependances (uniquement en 2.4) ; 

la compilation du noyau statique ; 

la compilation des modules, si necessaire. 

Toutes les phases de generation du noyau passent par l'utilisation de la commande make, 
large ment utilisee dans tous les developpements Unix et meme sur d'autres systemes 
d'exploitation. Le principe de cet utilitaire est de comparer la date des fichiers resultats 
par rapport a celle des fichiers sources en fonction de regies definies dans un fichier de 
commande nomme par defaut Ma kef i 1 e. Cela permet de generer uniquement les fichiers 
resultats dont les sources ont ete modifiees depuis la derniere generation. 

La configuration a pour objet de permettre de choisir parmi les multiples possibilites du 
noyau les fonctionnalites que Ton desire utiliser, par exemple l'utilisation de periphe- 
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riques SCSI ou le support de cartes ISDN. Dans le cas d'un systeme embarque, une confi- 
guration optimale, reduite aux strides fonctionnalites necessaires, sera indispensable tant 
au niveau des performances que de la taille du noyau. 

La configuration des options du noyau se fait par la commande : 

# make config 
rm -f include/asm 

( cd include ; In -sf asm-i386 asm) 
/bin/sh scripts/Configure arch/i'386/config.in 

# 

# Using defaults found in arch/i386/defconfig 



* Code maturity level options 

Prompt for development and/or incomplete code/drivers (CONFIG_EXPERIMENTAL) [N/y/?] 

Ce mode de configuration permet seulement une definition sequentielle en mode texte 
des diverses options du noyau, ce qui est tres difficilement utilisable dans les noyaux 
recents. En particulier, il n'est pas possible de revenir en arriere pour modifier une 
option. On preferera aujourd'hui la configuration pleine page du make menuconfig utili- 
sant la bibliotheque Curses ou bien la version X Window make xconf i g recourant au lan- 
gage de script Tcl/Tk. Dans le cas du noyau 2.6, la configuration graphique make xconf i g 
est desormais accessible a travers un programme base sur Qt. 

La figure 4-2 ci-apres indique l'ecran de dialogue obtenu lors du lancement de la com- 
mande make menuconfig: 



root@localhost.localdomain : /usr/src/linux - 2 .4 



Linux Kernel v2.4 H 



Arrow keys navigate the menu . < Enter) selects submenus > . 

Highlighted letters are hotkeys . Pressing <Y> includes , <N> excludes , 
<M> modularizes features . Press (EscXEsc) to exit , <?> for Help . 
Legend : [#] built-in [ ] excluded <M> module < > module capable 



-> 



-> 



oadable module support 
rocessor type and features 
eneral setup > 

M mory Technology Devices (MTD) 

arallel port support > 

lug and Play configuration > 

lock devices > 

M lti-device support (RAID and LVM) 

N tworking options > 



HEgESH 



< Exit > 



< Help > 



Figure 4-2 

Make menuconfig. 
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La figure ci-apres indique l'ecran de dialogue obtenu lors du lancement de la commande 
make xconf ig : 



Figure 4-3 

Make xconfig pour le noyau 2.4. 

Dans le cas du noyau 2.6, on obtient l'ecran suivant 



-1 


Linux Kernel Configuration 




- rn 


Code maturity level options 


SCSI support 








File systems 






Loadable module support 


Fusion MPT device support 


Console drivers 




Processor type and features 


IEEE 1394 (FireWire) support (EXPERIMENTAL) 


Sound 


General setup 


IZO device support 


USB support 


Memory Technology Devices (MTD) 


Network device support 


Bluetooth support 


Parallel port support 


Amateur Radio support 


Kernel hacking 


Plug and Play configuration 


IrDA (infrared) support 








Block devices 


ISDN subsystem 




Multi-device support (RAID and LVM) 


Old CD-ROM drivers (not SCSI, not IDE) 


Save and Exit 


■■ 




Networking options 


Input core support 


Quit Without Saving 




Telephony Support 


Character devices 


Load Configuration from File 




ATA/I DE/MFM/RLL support 


Multimedia devices 


Store Configuration 


to File 




— , 











- * 



ule option Help 

<n &U | || t; 



option 

7-General setup 
i — DConif igure standard kernel features ( 
[--Loadable module support 
- Processor type and Features 
] : — Firmware Drlveis- 
Fower management options (ACPI, APM) 
t— ACPI (Advanced Configuration and Pc 
I— APM (Advanced Power Management) 
■CPU Frequency scaling 
Bus options (PCI, PCMCIA, EISA, MCA. 
PCCARD (PCMC1A/CardEus> support 
PTI Hmplug Support 
F*pruta hip tilp rnrmaits 
Hpvlr p Drivers 

■Onprir Drivf r Options 
Mpmnry Tpfhnolngy rY'virps (MTr» 
Parallpl port support 
Plug JHtd Play support 
-■■Rlnrk ripvirps 

-IO Srhpriulpn 
i-ATA/ATAFI/MFM/RII support 
SCSI dpvlrp support 
Oldrr>ROMdrivprstnntSCSfl, not If 
Muttl-ripvlre support (RAIfland I VM> 



- 



option | 

-■■ 13 Prompt for development and/or incomplete code/drivers 
: --0Selec! only drivers expected to compile cleanly 



Code maturity level options 



Figure 4-4 

Make xconfig pour le noyau 2.6. 
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Le lecteur averti conviendra que cette derniere solution est de loin la plus efficace ! Ce 
meme lecteur notera que l'aspect de l'ecran de configuration du noyau est beaucoup plus 
inspire par la langue de Shakespeare que par celle de Pagnol, ce qui signifie qu'il faudra 
un minimum de maitrise de l'anglais technique pour s'attaquer a cette configuration. 

L'ecran obtenu en cliquant sur le premier bouton Code maturity level options est tres 
important car il conditionne l'affichage des ecrans de configuration des fonctionnalites 
les plus recentes. Si vous desirez utiliser ces fonctionnalites, vous devrez obligatoirement 
valider cette option comme indique ci-apres sur la figure suivante : 



-r- 






UjI 


Code maturity level options j 


♦ y 


V " 


v n 


Prompt for development and/or incomplete code/drivers 


Help 


















Main Menu 


Next 


1 















Figure 4-5 

Code maturity level options. 



En actionnant le bouton Help, on obtient un ecran d'aide affiche a partir du repertoire de 
documentation cite precedemment. Le symbole affiche en titre de la page d'aide, soit 
CONFIG_EXPERIMENTAL dans ce cas, sera utilise comme variable logique dans le fichier 
resultat de la configuration decrit plus bas dans cette section. 

Chaque variable logique pourra prendre deux ou trois etats selon le type de configura- 
tion : 

• Les configurations de type oui/non prendront les valeurs y/n. C'est le cas dans l'exem- 
ple precedent. 

• Les configurations concernant le support d'un protocole ou d'un peripherique pren- 
dront les valeurs y/n/m, le dernier etat correspondant au support par un module char- 
geable au lieu d'un support compile dans la partie statique du noyau. 

Un exemple de ce type de configuration est donne sur la figure 4-6 ci-apres : 

On notera dans cet exemple que la validation ou non d'une option peut entrainer l'acces 
ou non a d'autres options de configuration. 

Lorsque la configuration est terminee, celle-ci doit etre sauvegardee grace au bouton 
Save and exit situe en bas a droite de l'ecran principal. Par defaut, la configuration cou- 
rante sera sauvegardee sur le fichier . conf i g du repertoire des sources du noyau : 



§ Is -la .config 
-rw-r--r-- 1 root 



root 



15832 oct 28 00:17 .config 
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-\ 


Parallel port support 


— uv 


Parallel port support | 


v y 


♦ m 


v n 


Parallel port support 


Help 


A 


v y 


v m 


♦ n 


PC-style hardware 


Help 


v y 


v m 


v n 


Multi-IO cards (parallel and serial) 


Help 


v y 


v - 


v n 


Use FIFO/DMA if available (EXPERIMENTAL) 


Help 


v y 


v - 


v n 


SuperlO chipset support (EXPERIMENTAL) 


Help 


v y 


v m 


♦ n 


Support for PCMCIA management for PC- style ports 


Help 


v y 


v m 


♦ n 


Sparc hardware (EXPERIMENTAL) 


Help 


v y 


v - 


♦ n 


Support foreign hardware 


Help 


v y 


v - 


♦ n 


IEEE 1ZB4 transfer modes 


Help 






Main Menu 


Next Prev 


1 













Figure 4-6 

Parallel port support, exemple de configuration a 3 etats. 



En editant le fichier, on peut verifier la validation des options, comme le support des 
developpements recents ou du port parallele en module : 

# 

# Code maturity level options 
# 
CONFIG_EXPERIMENTAL=y 

# 

it Parallel port support 

# 

CONFIG_PARPORT=m 

# CONFIG_PARPORT_PC is not set 

# CONFIG_PARPORT_PC_PCMCIA is not set 

# CONFIG_PARP0RT_AMIGA is not set 

# C0NFIG_PARP0RT_MFC3 is not set 

# CONFIG_PARPORT_ATARI is not set 

# CONFIG_PARPORT_SUNBPP is not set 

# C0NFIG_PARP0RT_0THER is not set 

# C0NFIG_PARP0RT_1284 is not set 

L'utilitaire de configuration permet egalement de sauvegarder la configuration sous un 
nom different - Store configuration to file - ainsi que de charger une configuration a par- 
tir d'un fichier au format presente plus haut - Load configuration from file. 
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Notez bien 

Ces possibility seront particulierement utiles dans le cas de tests successifs lors de I'optimisation d'un noyau 
Linux embarque. 



La phase suivante est suggeree par l'utilitaire de configuration lors de la sauvegarde 
comme indique sur la figure suivante : 



3: 



Kernel build instructions 



JM 



End of Linux kernel configuration. Check the top-level Makefile for 
additional configuration. Next, you must run 'make dep'. 



Figure 4-7 

Sauvegarde de la configuration. 



La boite de dialogue indique a juste titre qu'il est possible de modifier le fichier Ma kef i 1 e 
avant de lancer les phases suivantes. En particulier, il peut etre tres interessant de modi- 
fier le parametre EXTRAVERSION situe en tete du fichier Makef i 1 e : 

# head Makefile 
VERSION = 2 
PATCHLEVEL = 4 
SUBLEVEL = 13 
EXTRAVERSION = -pf_testl 

Comme indique au debut du chapitre, la modification de ce parametre va permettre de 
faire cohabiter plusieurs versions identiques du noyau, correspondant a des tests succes- 
sifs. En particulier, les arborescences des modules seront suffixees par la valeur de 
1' EXTRAVERSION, ce qui donnera dans notre cas /lib/modules/2.4.13-pf_testl. 

Lorsque le fichier de configuration est au point, on doit creer les dependances des fichiers 
Makef i 1 e des differents sous-repertoires. Le fichier de configuration du noyau etant uni- 
que, le but de cette action est de propager les options choisies dans les sous-repertoires 
des sources du noyau. Pour cela, on doit effectuer un 

make dep 

comme indique par la boite de dialogue de la figure 4-7. Cette etape n'est pas necessaire 
dans le cas du noyau 2.6. Si on l'effectue en environnement 2.6, on obtient le message 
suivant : 



§ make dep 

*** Warning: make dep 



is unnecessary now. 
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La compilation de la partie statique du noyau par un simple : 

make 

generera le noyau sous forme non compressee sous le nom vmlinux dans le repertoire 
arch/i386/boot. Pour des raisons evidentes de taille du fichier noyau, on preferera la 
commande : 

make bzlmage 

qui generera un fichier compresse bzlmage au meme endroit. Le noyau contient lui-meme 
le code de decompression utilise lors du demarrage du systeme. 

A la fin de la compilation, on obtient le fichier noyau ainsi que le fichier System. map qui 
renferme la liste des adresses internes du noyau : 

# Is -1 System. map 
-rw-r--r-- 1 root root 438251 oct 28 01:03 System. map 

# Is -1 arch/i'386/boot/bzlmage 
-rw-r— -r-- 1 root root 848556 oct 28 01:03 arch/i'386/boot/bzlmage 

On doit ensuite copier ces fichiers dans le repertoire /boot contenant les noyaux du sys- 
teme, et ce en respectant la valeur de 1' EXTRAVERSION : 

Iii cp arch/i386/boot/bzImage /boot/bzImage-2.4.13_pf_testl 
# cp System. map /boot/System. map-2. 4. 13-pf_testl 

La phase suivante est la generation des modules chargeables qui representent la partie 
dynamique du noyau. Pour cela, on fait : 

make modules 

puis pour installer les modules : 

make modules_instal 1 

Astuce ! 

Lorsque la compilation du noyau n'aura plus de secrets pour vous, vous pourrez de fagon avantageuse enchaT- 
ner ces commandes en separant les differentes etapes par un point-virgule : make dep; make clean; etc. 
De meme, le resultat de la compilation peut etre redirige sur un fichier de trace en utilisant la syntaxe 
i>fichier_trace 2>&i & a la fin de I'enchainement de commandes make. 

La generation du nouveau noyau est alors terminee ; il reste a ajouter ce noyau dans le 
systeme de demarrage comme nous allons le voir dans la section suivante. 

Configuration du demarrage 

Pour le demarrage ou boot d'un systeme, on recourt le plus souvent a un programme de 
chargement ou loader. II existe divers programmes de chargement mais le plus utilise est 
certainement LILO, le Linux LOader. Le principe de LILO est similaire a celui des autres 
programmes de demarrage, a savoir installer un programme de chargement du systeme 
d' exploitation dans les 512 premiers octets du peripherique de demarrage, le plus sou- 
vent d'un disque dur. 
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LILO est configurable par un fichier unique 1 i 1 o . conf situe sur le repertoire /etc. 

La plupart des distributions generent un fichier de configuration similaire a celui decrit 
ci-apres : 

boot=/dev/hda 

map=/boot/map 

instal l=/boot/boot.b 

prompt 

timeout=50 

defaul t=l inux 

image=/boot/vml inuz-2.4.2-2 
1 abel=l inux 
read-only 
root=/dev/hda3 

Le parametre boot indique a LILO qu'il devra installer son secteur de demarrage (ou 
boot sector) sur le premier secteur du premier disque dur. C'est le cas le plus frequem- 
ment utilise, ce qui implique que LILO controle le demarrage de tous les systemes 
d' exploitation de la machine en cas d' installation multi-systeme. 

Le parametre map est automatique genere par LILO. 

Le parametre i nstal 1 indique a LILO le nom du nouveau fichier de secteur de boot a ins- 
taller. Ce fichier contient le code de demarrage a installer sur le premier secteur du dis- 
que. Le mot-cle read-only indique qu'il faut initialement monter le systeme de fichier en 
lecture seule, et ce en cas de verification d'integrite du systeme par la commande e2fsck. 
Cette verification a lieu si le systeme n'a pas ete arrete correctement, mais egalement a 
intervalles reguliers en fonction du nombre de montages du systeme de fichier au cours 
du temps. 

Le parametre image decrit un systeme d' exploitation a demarrer, en l'occurrence un 
noyau Linux a charger. Les sous -parametres 1 abel et root indiquent respectivement le 
nom symbolique a utiliser pour designer ce noyau, ainsi que la partition principale utili- 
sed par ce dernier. 

Les parametres prompt et timeout indiquent que LILO interrompra son chargement 
durant quelques dixiemes de secondes (ici 50) de maniere a laisser le temps a l'utilisateur 
d'entrer le nom d'une image comme cela a ete precedemment defini grace au sous- 
parametre label. Si l'utilisateur ne fait aucune action, l'image decrite par le parametre 
default sera chargee. Pendant ce temps de latence, l'utilisateur peut egalement entrer 
des parametres qui modifieront le comportement du demarrage du systeme. Pour forcer 
le systeme a demarrer au niveau 1 (mono-utilisateur ou single user), on entrera 1 i nux la 
l'invite LILO. Pour forcer la valeur de la taille de memoire vive a 128 Mo, on entrera 
MEM=128M. En cas d'utilisation systematique, ces parametres peuvent etre specifies dans le 
fichier /etc/1 i 1 o . conf grace a la directive append : 

append="MEM=128M" 

L'adjonction d'un nouveau noyau est tres simple car il suffit d'ajouter des lignes du type : 
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image=/boot/bzImage-2.4.13-pf_testl 
label =new 
read-only 
root=/dev/hda3 

ce qui permettra de charger l'image nominee new lors du demarrage du systeme. 

Dans le cas ou le demarrage du systeme necessite le chargement d'un pilote non integre 
dans la partie statique du noyau, on devra utiliser un disque memoire ou ramdisk initial. 
Ce disque memoire sera charge par un fichier genere a partir du noyau par la commande 
mkinitrd : 

I# mkinitrd initrd-2.4.13-pf_testl.img 2.4.13-pf_testl 
# Is -1 initrd-2.4.13 
-rw-r— r-- 1 root root 251444 oct 28 02:04 initrd-2.4.13-pf_testl.img 

La validation du nouveau parametrage et l'ecriture du nouveau secteur de demarrage se 
font par la commande : 

# /sbin/lilo -v 

LILO version 21.4-4, Copyright (C) 1992-1998 Werner Almesberger 

'lba32' extensions Copyright (C) 1999,2000 John Coffman 

Reading boot sector from /dev/hda 

Merging with /boot/boot. b 

Mapping message file /boot/message 

Boot image: /boot/vml inuz-2.4.2-2 

Added 1 inux * 

Boot image: /boot/bzImage-2.4.13-pf_testl 

Added new 



Tres important ! 

L'utilisation de la commande susmentionnee est indispensable apres chaque modification du noyau. En cas 
d'omission, le systeme pourrait ne plus etre en mesure de redemarrer. Dans tous les cas, nous vous conseillons 
de construire une disquette de demarrage comme cela est indique ci-apres. 



Si Ton ne desire pas modifier le secteur de demarrage du disque, le programme LILO peut 
egalement etre installe sur une disquette construite grace a la commande mkbootdi sk sur 
distribution Red Hat ou mkboot sur distribution DEBIAN : 

mkbootdisk --device /dev/fdO 2.4.13-pf_testl 

II est egalement possible de configurer le demarrage sans utiliser LILO ni aucun pro- 
gramme de chargement. Pour cela, il suffit de copier la partie statique du noyau Linux sur 
une disquette formatee par un simple : 

cp /boot/bzImage-2.4.13_pf_testl /dev/fdO 

puis d'indiquer a ce noyau ses differents parametres de demarrage en utilisant la com- 
mande rdev : 
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§ rdev --help 

usage: rdev [ -rsv ] [ -o OFFSET ] [ IMAGE [ VALUE [ OFFSET ] ] ] 
rdev /dev/fdO (or rdev /linux, etc.) displays the current ROOT device 



rdev /dev/fdO /dev/hda2 


sets ROOT to /dev/hda2 


rdev -R /dev/fdO 1 


set the 


ROOTFLAGS (readonly status) 


rdev -s /dev/fdO /dev/hda2 


set the 


SWAP device 


rdev -r /dev/fdO 627 


set the 


RAMDISK size 


rdev -v /dev/fdO 1 


set the 


bootup VIDEOMODE 


rdev -o N ... 


use the 


byte offset N 


root-flags ... 


same as 


rdev -R 


swapdev . . . 


same as 


rdev -s 


ramsize . . . 


same as 


rdev -r 


mode video . . . 


pare 


1 que rdev -v 


Note: les modes video sont : 


-3=Demander, 


-2=Etendu, -l=Normal Vga, l=touchel, 


*• 2=touche2 






utilisez -R 1 pour monter 


a racine en 


ecture seule, -R pour lecture/ecriture. 



Ce qui donne dans notre cas : 

rdev /dev/fdO /dev/hdal 

pour indiquer au noyau que son root filesystem est situe sur /dev/hdal, soit la premiere 
partition du premier disque IDE, puis : 

rdev -R /dev/fdO 1 

pour indiquer de monter initialement ce systeme de fichier en lecture seule. La disquette 
ainsi obtenue permet alors de demarrer un systeme. Cette methode necessite cependant la 
presence des pilotes de peripheriques indispensables au boot dans la partie statique du 
noyau, soit le fichier bzlmage. 

Repertoires et fichiers principaux 

Le systeme d' exploitation Linux est remarquablement bien organise en ce qui concerne 
la repartition des fichiers systeme. La raison principale en est 1' heritage des architectures 
Unix qui, en depit de leurs differences, surent garder une structure homogene et facile- 
ment comprehensible pour un administrateur teinte d'une culture Unix generique. En 
effet, meme si la guerre de Unix fit rage pendant de nombreuses annees, il sera relative- 
ment simple a un administrateur systeme Solaris, done System V, d'administrer un sys- 
teme FreeBSD ou Linux, la reciproque etant vraie. 

La seule difficulte reside le plus souvent dans la connaissance des outils d' administration 
proprietaires fournis par les editeurs ou constructeurs afin de faciliter le travail d' admi- 
nistration du systeme. Sachant qu'un veritable administrateur Unix oeuvre exclusivement 
a l'editeur de texte vi ou emacs, il n'y a pas beaucoup de souci a se faire de ce cote -la. 

L' organisation des fichiers d'un systeme Linux est definie par un document intitule dans 
sa version originale le Filesystem Hierarchy Standard (FHS) que Ton peut traduire par 

Standard d' organisation du systeme de fichiers. 

Ce document n'est pas une norme officielle mais vise a unifier l'organisation des syste- 
mes de fichiers Unix afin de faciliter le passage d'une version d'Unix a une autre. II est 
disponible sur Internet a l'adresse http://www.pathname.com/fhs. 
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Comme nous l'avons decrit dans la sous-section concernant le noyau Linux, ce dernier 
necessite la presence d'un systeme de fichiers principal ou racine appele root file system. 
La commande mount permet de connaitre la partition physique associee a ce systeme de 
fichier symbolise par le caractere slash (/). 

I# mount 
§/dev/hda2 on / type ext2 (rw) 

D'apres le FHS, le systeme de fichier de Linux est organise de la maniere suivante, du 
moins pour les entrees principales : 

/ -- racine du systeme 

+-bin Principales commandes utilisateur 

+-boot Hoyaux et chargeurs du systeme 

+-dev Pseudo fichiers des pilotes (devices) 

+-etc Fichiers de configuration 

+-lib Bibl iotheques partagees et modules 

+-mnt Points de montage temporal' res 

+-opt Applications externes 

+-sbin Principales commandes systeme 

+-tmp Fichiers temporal' res 

+-usr Hierarchie secondaire 

+-var Donnees variables 

Les differents systemes de fichiers situes en dessous de la racine sont divises en plusieurs 
categories : 

• Les systemes de fichier partageables ou sharables que Ton peut utiliser entre plusieurs 
machines, par exemple a travers un montage NFS. Dans la liste precedente, /opt est 
un de ceux-la. 

• Les systemes de fichier non partageables locaux a une machine. Dans la liste prece- 
dente, /etc est un de ceux-la. 

• Les systemes de fichier statiques qui ne sont pas modifies au cours du fonctionnement 
de la machine. Dans la liste precedente, /usr est un de ceux-la. 

• Les systemes de fichier variables qui sont modifies au cour du fonctionnement de la 
machine. Dans la liste precedente, /var est un de ceux-la. 

Les systemes de fichier statiques pourront etre montes en lecture seule ou read-only, 
alors que les systemes de fichier variables devront l'etre en lecture-ecriture ou read- 
write. Ces derniers points peuvent avoir une grande importance dans le cas d'un systeme 
embarque car cela peut conditionner la configuration materielle du systeme au niveau du 
type de peripherique de stockage. 

Le repertoire /bi n contient les commandes utilisateurs les plus communes (par exemple, 
/bin/Is). Ces commandes seront accessibles a tous les utilisateurs y compris bien 
entendu 1' administrate ur du systeme. Le repertoire /bin ne doit pas contenir de sous- 
repertoire. Une liste minimale de commandes disponibles est requise par le FHS. 
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Le repertoire /sbin contient les principales commandes systeme. Ces commandes sont 
theoriquement accessibles a 1' administrate ur root mais pas aux utilisateurs standards. 
Cependant, certaines commandes non destructrices seront accessibles a l'utilisateur stan- 
dard a condition de donner le chemin d'acces complet de la commande. 

Le repertoire /boot a ete longuement cite dans la sous-section concernant le noyau 
Linux. Ce repertoire contient en effet les parties statiques du noyau Linux ainsi que les 
fichiers auxiliaires comme la carte memoire interne du noyau ou System. map. Le reper- 
toire contient egalement les fichiers utilises par le chargeur LILO. 

Le repertoire /dev contient les pseudo-fichiers ou devices associes aux pilotes de peri- 
pheriques. Les pilotes sont en effet accessibles a travers des fichiers speciaux appeles 
egalement nceuds (ou nodes). Ces fichiers sont caracterises par deux valeurs numeriques : 

• le majeur ou major qui identifie le pilote ; 

• le mineur ou minor qui represente une sous-adresse en cas de presence de plusieurs 
peripheriques identiques, controles par un meme pilote. 

L'exemple ci-apres donne la liste des fichiers speciaux associes aux pilotes des ports 
series : 

# Is -1 /dev/ttyS* 

crw i root tty 4 _ 6 4 mai 5 19 9 8 /dev/ttySO 

crw i root tty 4| 6 5 mai 5 19 g 8 /dev/ttySl 

crw i root tty 4> 66 mai 5 1998 /dev/ttyS2 

crw i root tty 4> 67 mai 5 1998 /dev/ttyS3 

Dans ce cas- la, le majeur vaut 4 et les mineurs vont de 64 a 67. Pour creer une nouvelle 
entree dans le repertoire /dev, on utilise la commande mknod : 

mknod /dev/monpilote c majeur mineur 

Le caractere « c » indique que Ton dialogue avec le peripherique en mode caractere. Ce 
mode indique que Ton peut echanger avec le peripherique un nombre variable d'octets. 
On peut aussi utiliser des peripheriques en mode bloc, ce qui impose de dialoguer par 
blocs de donnees. La memoire de masse est un exemple de peripherique en mode bloc. 
Dans ce cas, 1' entree dans le repertoire /dev sera creee avec 1' option « b » a la place 
de « c » : 

mknod /dev/monpilote b majeur mineur 

Le repertoire /etc contient la majorite des fichiers et sous-repertoires de configuration du 
systeme. Ce repertoire ne doit pas contenir de fichiers executables. Les sous-repertoires 
sont classes en fonction du type de configuration associe, par exemple : 

• /etc/sysconf i g pour la configuration generale du systeme, 

• /etc/Xll pour la configuration de l'interface graphique X Window System. 

Plus generalement, le repertoire /etc/machin_truc contiendra les fichiers de configura- 
tions specifiques a 1' application machin_truc. 
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Ce repertoire renferme en particulier le fichier /etc/i ni ttib contenant lui-meme le nom 
du script de demarrage lance par le processus /sbin/init ou son remplacant, lui-meme 
lance par le noyau Linux. 

On notera egalement que le repertoire /etc/ red contient les scripts de demarrage du 
systeme. Linux utilise pour cela le systeme des niveaux d'execution ou run levels intro- 
duit par Unix System V. Base sur le lancement de services en fonction du niveau d'execu- 
tion, ce systeme a le gros avantage de definir proprement la localisation des differents 
scripts de demarrage dans des sous-repertoires correspondant aux niveaux : 



# Is -1 /etc 
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Les niveaux d'execution sont les suivants : 

Arret 

1 Mode utilisateur unique ou single user mode 

2 Multi-utilisateur {multi-user) sans NFS 

3 Multi-utilisateur complet 

4 Non utilise 

5 X Window System, interface graphique 

6 Redemarrage 

Ce principe de fonctionnement sera explicite plus longuement au chapitre 5 et nous 
verrons qu'il n'est pas forcement adapte aux contraintes d'un environnement reduit. 

Le repertoire /lib contient les bibliotheques principales du systeme ainsi que les modu- 
les du noyau. Comme tous les systemes d' exploitation modernes, Linux utilise un sys- 
teme de bibliotheques partagees ou shared libraries qui permet de ne stacker une 
bibliotheque utilisee par plusieurs programmes qu'une seule fois dans le systeme. 

D'autres avantages sont induits, par exemple la mise a jour unique par simple remplace- 
ment de la bibliotheque partagee et bien stir 1' optimisation de la memoire en cas d'utili- 
sation simultanee de la bibliotheque par plusieurs programmes. 

Le repertoire /lib doit contenir les bibliotheques partagees utilisees par les commandes 
des repertoires /bin et /sbin. 
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Pour connaitre les bibliotheques partagees utilisees par un programme, on peut utiliser la 
commande 1 dd : 

I§ ldd /bin/cp 
libc.so.6 => /lib/libc.so.6 (0x4001c000) 
/lib/ld-linux.so.2 => /I ib/ld-1 inux.so.2 (0x40000000) 

La totalite des programmes Linux utilise ces deux bibliotheques : 

• libc.so.6 est la bibliotheque principale du systeme aussi appelee glibc ; 

• ld-linux.so.2 est le chargeur ou loader qui permet de charger les bibliotheques 
necess aires au programme. 

Le nom d'une bibliotheque partagee correspond souvent a un lien symbolique sur la ver- 
sion reelle de la bibliotheque, ce qui permet de faire coexister plusieurs versions de 
bibliotheques partagees : 

I# Is -1 /lib/libc* 
-rwxr-xr-x 1 root root 4101324 fev 29 2000 /I ib/1 ibc-2.1 .3. so 
Irwxrwxrwx 1 root root 13 sep 25 2000 /lib/libc.so.6 -> 1 ibc-2. 1.3. so 

D'autres repertoires comme /usr/1 i b peuvent contenir des bibliotheques partagees utili- 
sees par les commandes du repertoire /usr/bin. Hormis /lib, la liste des repertoires 
explores pour la recherche des bibliotheques partagees se trouve dans le fichier /etc/ 
ld.so.conf : 

# cat /etc/Id. so. conf 

/usr/XHR6/lib 

/usr/1 ib 

/usr/kerberos/1 ib 

/usr/i 486-1 inux-1 ibc5/l ib 

/usr/local /lib 

Si Ton souhaite ajouter un repertoire, il faut l'ajouter a cette liste et utiliser la commande 
/sbin/ldconfig pour valider la modification et creer le fichier /etc/Id. so. cache. 

Le repertoire /usr est une hierarchie secondaire c'est-a-dire qu'elle contient des sous- 
repertoires de commandes utilisateur comme /usr/bi n, des commandes systeme comme 
/usr/sbin ou de bibliotheques partagees comme /usr/1 ib. Cette hierarchie pourra 
egalement contenir d'autres sous-repertoires comme l'arborescence X Window System 
sur /usr/XHR6. 

Le repertoire /mnt contient les points de montage temporaires comme /mnt/cdrom. 
Ces points de montage pourront etre ajoutes dans le fichier I etc I f stab : 

/dev/cdrom /mnt/cdrom iso9660 noauto.owner.ro 

chaque champ indiquant respectivement le peripherique a monter, le point de montage, le 
type de systeme de fichier a utiliser et les options de montage. 

Le repertoire /tmp est une zone de stockage de fichiers temporaires utilises par exemple par 
le compilateur gcc. Dans le cas d'un systeme embarque, on veillera a ce que ce repertoire 
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soit vide automatiquement a chaque demarrage du systeme, ce qui n'est pas le cas des 
distributions standards. 

Le repertoire /var est une zone de stockage de donnees variables, en particulier : 

• Les fichiers verrous ou lock files permettant d' assurer l'unicite d'utilisation de certai- 
nes ressources comme les ports series. Ces fichiers sont localises sur le repertoire /var/ 
lock et contiennent le numero de processus ou PID (Process IDentifier) du processus 
ayant verrouille le peripherique. 

• Les fichiers de trace ou log files qui contiennent les traces d' execution de certains pro- 
grammes. Le repertoire utilise est /var/log et le fichier principal de trace est /var/ 
log/messages. Dans le cas d'un systeme embarque, on veillera bien sur a limiter les 
traces au strict minimum. La plupart des distributions utilisent cependant des systemes 
de purge automatique des fichiers de trace. 

• Les files d'attente ou spool directories qui permettent de stacker temporairement des 
fichiers en attente de traitement par un autre processus. Le repertoire utilise est /var/ 
spool . 

• Les fichiers de fonctionnement ou pid files qui indiquent simplement qu'un pro- 
gramme donne tourne a l'instant present avec le PID inscrit dans le fichier. Le format 
du fichier est le plus souvent nom_du_programme.pid. 

Ce repertoire est un facteur de risque important concernant les problemes de remplissage 
de disque et devra etre traite de maniere tres attentive dans le cas du developpement d'un 
systeme embarque. 

En resume 

Le systeme Linux a une structure similaire a celles des autres versions d'Unix. L' organi- 
sation des fichiers dans le systeme est conforme au Filesystem Hierarchy Standard (FHS) 
ou Standard d' organisation du systeme de fichiers. 

Le noyau Linux est monolithique mais on peut charger et decharger dynamiquement des 
modules. 

Le systeme de fichier virtuel /proc permet d'acceder facilement aux parametres du sys- 
teme et particulierement a ceux du noyau. 

La compilation du noyau, et ce afin de 1' adapter aux besoins de 1' application, est presque 
toujours necessaire dans le cas d'un projet de systeme embarque. 

Le chargement initial du noyau dans la memoire du systeme necessite le plus souvent 
l'utilisation d'un logiciel annexe appele chargeur. LILO est un exemple frequent de logi- 
ciel chargeur. Le noyau peut egalement etre charge a partir d'une disquette de demarrage. 
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Ce chapitre decrit la methode generale de creation d'un systeme Linux embarque a partir de 
composants directement extraits d'une distribution classique, ou bien generes a partir des 
sources. 



Les distributions classiques 

La distribution classique vise en premier lieu non pas 1' optimisation de l'espace utilise, 
pas plus que l'obtention des performances optimales, mais plutot la facilite d' installation. 
Linux a longtemps souffert - et souffre toujours - des sarcasmes de ses detracteurs qui 
le presentent comme un systeme esoterique et difficile a installer. Soumis a la pression 
concurrentielle et marketing, car tenus de rendre des comptes a leurs actionnaires, les 
editeurs de distributions ont fortement investi dans la convivialite de la procedure d' ins- 
tallation, ainsi que dans l'integration optimale de la distribution dans un environnement 
materiel generique. 

Le plus avance sur ce domaine est l'editeur francais Mandriva (http::/www.mandriva.com) 
qui s'est clairement positionne sur ce terrain, meme s'il est certainement le plus mine, car 
subissant le plus l'hegemonie de Microsoft. Le resultat est cependant a la hauteur des 
attentes comme on peut le constater sur la figure 5-1 ci-apres. 

Bien que le sujet de la convivialite du bureau ne soit pas notre preoccupation principale 
dans cet ouvrage, il faut reconnaitre que Mandriva a certainement participe de la popula- 
rity de Linux parmi les utilisateurs de Windows, autrefois rebutes par le cote austere de 
Linux. Meme si Ton peut emettre des reserves sur le fait qu'une interface graphique soit 
systematiquement plus simple a utiliser qu'un outil en mode texte, il faut louer Mandriva 
pour son effort de proselytisme et de vulgarisation ! 
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Figure 5-1 

Bureau KDE multilingue de Mandriva Linux. 



Le leader mondial, l'americain Red Hat Software (http://www.redhat.com), a toujours eu 
un positionnement quelque peu different car bien plus oriente vers le coeur du systeme, en 
1' occurrence le noyau Linux. Red Hat argue du point de vue commercial que 70 % des 
developpeurs principaux du noyau sont salaries de Red Hat et que de ce fait la societe est 
la plus grosse concentration d'expertise Linux au monde. Force est de constater que 
P argument est valide d'autant que Red Hat controle egalement la societe Cygnus, figure 
emblematique de POpen Source durant Pere pre-linuxienne et employeur des principaux 
developpeurs du compilateur gcc et du debogueur gdb. En raison du ciblage different de 
la population d'utilisateurs, Papproche de la distribution Red Hat est beaucoup plus 
stride comme le montre la figure 5-2 ci-apres. 

Pour les puristes, Red Hat fournit egalement une interface d' installation en mode texte. 
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Figure 5-2 

Procedure d' installation Red Hat 7.2. 




Figure 5-3 

Procedure d' installation Red Hat 7.2 (mode texte). 
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En dehors du niveau de sophistication graphique, les deux produits installent a peu pres 
les meme composants, et la procedure se passe la plupart du temps sans encombre et 
necessite le moins de dialogue possible avec la machine. Cette fluidite a forcement un 
revers, en l'occurrence, la difficulte aujourd'hui d'installer une distribution recente dans 
moins d'l Go de disque, ce qui n'est pas forcement un probleme pour la cible d'utilisa- 
teur concernee puisque la taille minimale des disques etait de 10 Go fin 2002 au moment 
de l'ecriture de la premiere version de cet ouvrage, elle est actuellement de 40 Go. L'eva- 
luation rapide est edifiante, sur un systeme Red Hat 7.2 configure en installation « ordi- 
nateur portable ». Le volume utilise, ne serait-ce que pour les modules du noyau, est deja 
significatif : 

Icd /lib/modules/2.4.7-10/ 
[pierre@localhost 2.4.7-10]$ du -s . 
25744 

soit environ 25 Mo, sans parler de celui des bibliotheques partagees « essentielles » qui 
avoisine les 10 Mo rien que sur le repertoire /l i b. Sur une distribution plus recente (Red 
Hat 9.0) le volume est encore de 10 Mo superieur : 

I# cd /lib/modules/2.4.20-8/ 
[root@localhost 2.4.20-8]# du -s . 
30296 

Le volume total de ces deux seuls repertoires est deja largement superieur a l'espace total 
alloue pour la majorite des systemes embarques typiques, ce dernier se situant en general 
entre 5 et 10 Mo pour un systeme fonctionnel incluant les services reseau habituels tels que 
FTP, Telnet, HTTP ou SSH. C'est done plus qu'un euphemisme de dire que les procedures 
d' installation classiques ne sont pas du tout adaptees au monde de l'embarque. 
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Au vu des conclusions auxquelles on parvient a la section precedente, quelles solutions 
s'offrent done a nous ? 

L'approche la plus simple est de se rabattre vers les distributions embarquees dites « spe- 
cialises ». Celles-ci se presentent sous forme de produits commerciaux (Montavista 
Linux, Lynux Works, BlueCat, etc.) ou bien de projets Open Source (LEAF, LRP, ELDK, 
Crosstools, etc.). Certains de ces produits fournissent des procedures d' installation con- 
viviales et permettent au novice d'obtenir assez rapidement un systeme fonctionnel. Le 
principal probleme est souvent le manque de « granularite » dans le choix des compo- 
sants, ce qui a pour effet d'obtenir un resultat qui n'atteint pas le maximum d'optimisa- 
tion, en particulier au niveau de la taille occupee. Cette approche est interessante si Ton 
souhaite peu s'investir intellectuellement sur le sujet. 

L'approche radicalement opposee consiste a partir de composants independants d'une quel- 
conque distribution, par exemple LinuxFromS cratch (http://www.linuxfromscratch.org), puis 
d'assembler les briques jusqu'a obtention d'un systeme « parfait ». Cette approche est rela- 
tivement extremiste et nous conseillons de la limiter a quelques elements du systeme. 



Construction du systeme 
Chapitre 5 

L'approche intermediaire est celle que nous preconiserons dans ce chapitre. Le but est 
de partir d'une distribution eprouvee (en l'occurrence la Red Hat 7.2), ce qui garantit 
la validite des differents composants. 

Remarque 

Les concepts exposes restent bien entendu valides dans le cas des versions plus recentes comme la Red Hat 9.0 
ou les nouvelles Fedora Core 2 et 3. En cas de differences notables, celles-ci seront explicitees. 

Un assemblage harmonieux de ces composants - quitte a les adapter a notre besoin - per- 
mettra d'obtenir assez rapidement un resultat fonctionnel. Cette approche a en commun 
avec l'approche precedente la volonte d' avoir la maitrise et la comprehension du sys- 
teme, point de vue que nous defendrons systematiquement dans cet ouvrage, et qui est 
absolument fondamental dans l'environnement industriel et embarque. 

La methodologie, directement issue du bon sens (qui est souvent la meilleure des metho- 
dologies), se resume en trois points. 

Le premier consiste a assimiler le fonctionnement du systeme Linux, ce qui n'est pas tres 
complique puisque Linux, et plus generalement Unix, est un des systemes les plus sim- 
ples et logiques qui soient. 

Le deuxieme point consiste a extraire les elements essentiels du systeme de maniere a 
n'utiliser que ces derniers pour la construction de la cible finale. Dans ce domaine, la 
moindre hesitation concernant l'utilite d'un composant peut conduire a l'installation de 
donnees superflues si ce composant est lie a d'autres elements. 

Enfin le troisieme point consiste a utiliser, en plus de la notre, 1' intelligence des autres - 
en l'occurrence celle des createurs de distributions - de maniere a adapter les differents 
composants en fonction de 1' analyse du deuxieme point. 

Quels sont les elements importants d'un systeme Linux dans un environnement embarque ? 

A la section « Repertoires et fichiers principaux » du chapitre precedent, on a soigneuse- 
ment decrit les differents composants du FHS (Filesystem Hierarchy Standard). Nous 
nous contenterons ici de lister les composants essentiels. 

Sur le plan pratique, la suite du chapitre indiquera la demarche qu'il faut suivre dans le 
cas d'une distribution embarquee construite a partir d'une Red Hat 7.2 sur un systeme 
de type x86. La raison principale de ce choix tient a ce que sa mise en application est 
largement facilitee pour la majorite des lecteurs. 

Le programme de demarrage 

Ce composant est essentiel dans la majorite des cas car il permet de charger l'image du 
noyau dans la memoire du systeme. Decrit au chapitre precedent, LILO, est encore le 
programme le plus utilise. Certains soucis de compatibilite avec les disques de grande 
taille ont conduit a son remplacement par GRUB - issu du projet GNU-Hurd - dans cer- 
taines distributions comme la Red Hat version 7.2 ou superieure. 

Pour certaines architectures et cartes mere x86, il est cependant possible de remplacer le 
BIOS par un noyau Linux adapte, comme decrit dans le projet http://www.linuxbios.org. 
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On pourra aussi s'affranchir de l'utilisation d'un programme de demarrage si Ton cree un 
peripherique « bootable » - par exemple une disquette - en effectuant une copie bloc a 
bloc du noyau sur ce peripherique via les commandes dd et rdev. 

Le noyau 

Le noyau Linux est le seul element reellement essentiel. Apres chargement et detection 
des peripheriques principaux, le comportement par defaut tient au demarrage du pro- 
gramme /sbin/init qui se charge de la suite du demarrage du systeme. Le programme 
de demarrage LILO comporte une option permettant de remplacer 1' execution du pro- 
gramme in it par un autre, ce qui peut permettre de lancer un programme applicatif 
directement depuis le noyau. 

LILO: linux init=/bin/mon_programme 

Cette fonction est cependant relativement limitee puisque l'acces aux ressources du sys- 
teme devra se faire entierement par 1' applicatif en question. 

L optimisation du noyau, c'est-a-dire la selection exclusive des fonctionnalites et pilotes 
necessaires, aura un fort impact sur le temps de demarrage du systeme qui est souvent 
une contrainte primordiale pour un systeme embarque. 

Les fichiers de configuration (/etc) 

Les fichiers de configuration sont localises dans le repertoire /etc. Dans un systeme Linux 
classique, le nombre de fichiers et sous-repertoires est assez consequent meme si l'espace 
utilise reste modeste. Un rapide test sur une Red Hat 7.2 donne les resultats suivants : 

[root@local host dev]# cd /etc 

[root@l oca! host etc]# find . -print | wc -1 

1437 
[rootOlocal host etc]# du -s . 
6916 . 

L optimisation du repertoire aura pour but initial la simplification de la structure. 

Les pseudo-fichiers ou nceuds (/dev) 

Les noeuds ou nodes sont situes dans le repertoire /dev. Ce ne sont pas des fichiers en tant 
que tels et chaque entree ne consomme qu'un inode dans le systeme de fichiers : 

I [rootOlocal host etc]# du -s /dev 
272 /dev 

Les programmes essentiels (/sbin et /bin) 

Les commandes essentielles a la configuration du systeme sont en general localisees dans 
le repertoire /sbi n. Le meilleur exemple en est la commande i ni t qui correspond au pre- 
mier processus lance par le noyau. Ce repertoire ne contient normalement pas de com- 
mande directement accessible a un utilisateur non privilegie. 
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Certaines commandes essentielles sont egalement situees sur /bin, comme la commande 
mount qui permet le montage du systeme de fichier principal (root filesystem) au demarrage. 
Pour simplifier la structure du systeme cible, toutes les commandes seront situees sur ces 
deux repertoires et nous n'utiliserons done pas les repertoires /usr/bin et /usr/sbin. 



Remarque 

Si le systeme ne necessite pas la version complete des utilitaires Linux, on pourra avantageusement se tourner 
vers BusyBox, (http://www.busybox.net), un projet Open Source tres actif depuis quelques annees et dont le but 
est de remplacer I'arborescence Linux par une version simplifiee basee sur un executable unique qui remplace 
les commandes classiques. 

Dans cette nouvelle edition de I'ouvrage, nous consacrerons une partie de ce chapitre a la description de la mise 
en place de BusyBox. 



Les bibliotheques essentielles (/lib) 

Ce repertoire contient les bibliotheques partagees indispensables au fonctionnement du 
systeme, done utilisees par les programmes situes sur /bin et /sbin. 

Les repertoires variables (/var) 

Le repertoire /var contient des fichiers et sous-repertoires dont l'encombrement peut 
augmenter fortement au cours du fonctionnement d'un systeme Linux classique. C'est la 
raison pour laquelle ce repertoire est habituellement situe sur une partition dediee. Dans 
le cas d'un systeme embarque, l'utilisation du repertoire sera limitee aux sujets suivants : 

• fichiers de fonctionnement ou pid-files, 

• fichiers verrous ou lock-files, 

• fichiers de trace ou log-files. 

Les deux premiers sont tres peu consommateurs en espace. La partie fichier de trace doit 
etre etudiee avec soin. Avec le repertoire /tmp, c'est le seul repertoire dont la taille est 
susceptible d'augmenter de maniere significative durant la vie du systeme. 

Creation dune partition dediee 

Lors de la creation du systeme, une methode simple est de travailler sur une partition 
dediee, creee specialement sur le poste de developpement. Le remplissage de la partition 
se fera au fur et a mesure de l'avancement en copiant peu a peu les composants de la dis- 
tribution standard - soit le disque de developpement - vers la partition dediee. Dans 
l'exemple qui suit, cette partition sera initialisee en utilisant le format extl ou ext3 stan- 
dards sur la distribution Red Hat 7.2. Le chapitre 7 traitera plus en detail le choix final du 
systeme de fichier pour l'optimisation de la distribution definitive. 
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Remarque 

Le format ext3 est totalement compatible avec le format ext2 sauf qu'il utilise en plus un journal interne des modifica- 
tions qui permet une plus grande securite de fonctionnement et un redemarrage rapide en cas d'arret intempestif. 



Une validation de la partition de test se fera de temps a autre en redemarrant le systeme 
sur cette partition. La taille de la partition est a evaluer selon les besoins du systeme cible. 
Lorsque le systeme sera valide sur le poste de developpement, il restera a le transferer sur 
la cible et a finaliser la procedure de boot sur cette meme cible. 

Si la memoire de masse utilisee par la cible est adaptable sur le poste de developpement, on 
pourra bien sur travailler directement sur l'espace cible. Le chapitre 3, traitant des solutions 
materielles, decrit quelques exemples d'outillages permettant d' adapter des memoires flash 
de type CompactFlash, DiskOnChip ou disque flash 2,5 pouces sur un PC classique. 

La partition est creee avec l'outil fdisk. Nous utilisons un deuxieme disque connecte en 
« esclave » sur le premier bus IDE. Ce disque est done identifie par le device /dev/hdb. 

# fdisk /dev/hdb 

Commande (m pour aide) : p 

Disque /dev/hdb : 15 tetes, 56 secteurs, 989 cylindres 
Unites = cylindres sur 840 * 512 octets 



Peri pheri que A 


morce 


Debut 


Fin 


Blocs 


Id 


Systeme 


/dev/hdbl 




1 


79 


33152 


83 


Linux 


/dev/hdb2 




80 


158 


33180 


83 


Linux 



Nous creons une nouvelle partition primaire (troisieme partition) d' environ 40 Mo. Nous 
rappelons qu'il est possible de creer 4 partitions primaires sur un disque. 

Commande (m pour aide) : n 
Action de commande 

e Etendue 

p Partition primaire (1-4) 

P 

Nombre de partitions (1-4): 3 

Premier cylindre (159-989, 159 par defaut) : 

Utilisation de la valeur par defaut 159 

Dernier cylindre ou +size ou +sizeM ou +sizeK (159-989, 

Une fois la partition creee, nous validons la modification. 

Commande (m pour aide) : p 
Disque /dev/hdb : 15 tetes, 56 secteurs, 

Unites = cylindres sur 840 * 512 octets 

Peripherique Amorce Debut Fin 

/dev/hdbl 1 79 

/dev/hdb2 80 158 

/dev/hdb3 159 256 



989 par defaut) : +40M 



989 cyl 


indres 


Blocs 


Id 


Systeme 


33152 


83 


Linux 
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83 


Linux 


41160 


83 


Linux 
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Commande (m pour aide) : w 

La table de partition a ete modifiee ! 

Appel de ioctlO pour relire la table de partition. 

AVERTISSEMENT: Si vous avez cree ou modifie 

une partition DOS 6.x, reportez-vous au manuel de fdisk 

pour plus d' informations. 

Synchronisation des disques. 

II faut maintenant formater la partition en ext3. Pour cela, il suffit d'utiliser la commande 
mke2fs. L' option -j permet de creer le journal interne, done un systeme ext3. 

# mke2fs -j /dev/hdb3 

mke2fs 1.23, 15-Aug-2001 for EXT2 FS 0.5b, 95/08/09 

warning: 199 blocks unused. 

Filesystem label = 
OS type: Linux 
Block size=1024 (log=0) 
Fragment size=1024 (log=0) 
10320 inodes, 40961 blocks 

2058 blocks (5.02%) reserved for the super user 
First data block=l 
5 block groups 

8192 blocks per group, 8192 fragments per group 
2064 inodes per group 
Superblock backups stored on blocks: 
8193, 24577 

Writing inode tables: done 

Creating journal (4096 blocks): done 

Writing superblocks and filesystem accounting information: done 

This filesystem will be automatically checked every 23 mounts or 
180 days, whichever comes first. Use tune2fs -c or -i to override. 



Un systeme de fichier de type ext2 est systematiquement verifie a intervalles reguliers. 
Cette option n'est pas utile dans le cas du systeme de fichier ext3 et Ton pourra inhiber 
cette verification en utilisant la commande tune2f s. 

# tune2fs -i /dev/hdb3 

tune2fs 1.23, 15-Aug-2001 for EXT2 FS 0.5b, 95/08/09 
Setting interval between check seconds 

# tune2fs -c /dev/hdb3 

tune2fs 1.23, 15-Aug-2001 for EXT2 FS 0.5b, 95/08/09 
Setting maximal mount count to -1 
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La partition peut maintenant etre montee sur un point de montage temporaire du type 
/mnt/emb. 



mkdir -p /mnt/emb 

mount -t ext3 /dev/hdb3 /mnt/emb 



I 

On peut egalement ajouter le montage dans la table /etc/f stab. 

/dev/hdb3 /mnt/emb ext3 noauto 

II suffira alors de taper mount /mnt/emb pour monter le systeme de fichier. 

Creation des repertoires 

Le systeme de fichier nouvellement cree ne contient rien mis a part le repertoire 
lost+found. Ce repertoire est utilise par le pilote du systeme de fichier pour stacker les 
portions de fichiers recuperees en cas de probleme grave sur la partition. 

# mount /mnt/emb 

# cd /mnt/emb 

# Is -1 
total 12 
drwxr-xr-x 2 root root 12288 jui 19 2001 lost+found 

Le fonctionnement du systeme Linux necessite la creation d'un certain nombre de reper- 
toires, indispensables ou utiles. 

Icd /mnt/emb 
mkdir bin boot dev etc lib proc root sbin tmp usr var 

Le repertoire /tmp necessite des droits d'acces particuliers, en l'occurrence les droits de 
lecture/ecriture/parcours pour tous les utilisateurs. 

chmod a+rwx /tmp 

Pour preparer la suite de l'installation, nous pouvons creer quelques sous-repertoires uti- 
les pour la suite. 

mkdir -p usr/1 ib/kbd/keytables 
pour stocker les tables de definition de la geometrie des claviers. 

mkdir -p var/log var/run 
pour stocker les eventuels fichiers de trace et de fonctionnement. 

mkdir -p etc/sysconfig 
pour stocker la configuration du systeme, en particulier au niveau reseau. 
L' option -p indique de creer toute l'arborescence des repertoires si celle-ci est inexistante. 
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Le repertoire /extra 

II est interessant de creer un repertoire contenant des commandes et bibliotheques 
associees, dont on se sert uniquement pour la phase de mise au point. Dans ces comman- 
des de mise au point, on peut citer un editeur de texte comme vi ou bien des commandes 
comme 1 dd. Le principe est de creer un repertoire /extra ainsi que les repertoires neces- 
saires comme /extra/bin ou /extra/lib. La localisation de ces composants presente 
cet interet que Ton peut a tout moment estimer l'espace qu'ils occupent, et done avoir 
une bonne visibilite de l'empreinte memoire du systeme. Pour obtenir un systeme opti- 
mise, il suffira de supprimer le repertoire /extra. 

La creation des repertoires se fait de maniere classique. 

Icd /mnt/emb 
mkdir -p /extra/bin /extra/lib 



Remarque 

II est necessaire de modifier le fichier /etc/Id. so. conf afin d'y ajouter le repertoire /extra/lib. II taut 
ensuite taper ideonfig pour validercette modification. De meme, pour plus de commodite, il est conseille 
d'ajouter /extra/bin a la variable PATH. 



Creation des nceuds sur /dev 

Les distributions Linux fournissent la commande MAKEDEV afin d'initialiser le repertoire /dev 
en creant sur ce dernier les differents points d'entree ou nceuds. Curieusement, la com- 
mande MAKEDEV est situee sur le repertoire /dev de la distribution Red Hat 7.2. 

# rpm -ql MAKEDEV | more 

/dev/MAKEDEV 

/etc/makedev.d 

/etc/ma kedev.d/OOmacros 

/etc/ma kedev.d/at a raid 

Pour creer les noeuds principaux sur le repertoire /mnt/emb/dev, il suffit de proceder a : 



§ /dev/MAKEDEV - 
create mem 
create kmem 
create port 

create parport6 
create parport7 



-d /mnt/emb/dev generic console 

ell root: kmem 640 
c 1 2 root: kmem 640 
c 1 4 root: kmem 640 



99 
99 



6 root:lp 660 

7 root:lp 660 



Une rapide verification du repertoire indique que les nceuds ont bien ete crees et ne con- 
somment que tres peu d'espace. 



§ Is -1 /mnt/emb/dev 
3041 
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# du -s /mnt/emb/dev/ 
50 /mnt/emb/dev 



On pourra bien sur ajouter ulterieurement des noeuds en utilisant la commande mknod 
decrite au chapitre precedent. 

Remplissage de /bin /et /sbin 

Dans un premier temps, nous copierons seulement sur ces repertoires les programmes 
indispensables au demarrage d'un systeme minimal : 

• /sbin/init, premier programme demarre par le noyau et done premier processus du 
systeme (son PID vaut 1) ; 

• /sbi n/update, charge de vider le cache sur le disque a intervalles reguliers ; 

• /bin/mount, charge de monter le systeme de fichier principal ou root filesystem ; 

• /bi n/rm, utilise par le script de demarrage re . S pour effacer certains fichiers de fonc- 
tionnement ; 

• /bin/sh, interpreteur de commande, lance en fin d'initialisation du systeme. Dans 
notre exemple, nous utiliserons la version classique bash mais il existe des versions 
plus legeres comme ash (6 fois plus petit en taille) qui sont souvent plus adaptees a des 
distributions finales de systemes Linux embarques. 

II suffit pour cela de copier les fichiers au moyen des commandes : 

Icp /bin/bash /bin/mount /mnt/emb/bin 
cp /sbin/init /sbin/update /mnt/emb/sbin 

II est egalement necessaire de positionner un lien symbolique entre bash et sh. 

Icd /mnt/emb/bin 
In -s bash sh 



Un peu d'histoire 

Le programme interpreteur de commande sous Unix est appele Bourne-Shell, en I'honneur de son createur 
Steve Bourne, et ce depuis le debut du developpement d'Unix. La version GNU du « shell » fut done appelee 
bash, pour Bourne-Again-Shell. 



Creation des bibliotheques sur /lib 

Les commandes precedentes utilisent des bibliotheques partagees et le contenu du reper- 
toire /lib est done indissociable des repertoires /bin et /sbin. Comme precise au chapi- 
tre 4, nous rappelons qu'il est possible de connaitre la liste des bibliotheques utilisees par 
un programme en utilisant le script /sbin/ldd. Lexemple suivant indique les bibliothe- 
ques utilisees par l'interpreteur de commande bash. 
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# cd /mnt/emb/bin 

# ldd bash 

libtermcap.so.2 => /I ib/1 ibtermcap.so.2 (0x4002d000) 
libdl.so.2 => /lib/libdl .so. 2 (0x40031000) 
libc.so.6 => /lib/i686/libc.so.6 (0x40035000) 
/lib/ld-linux.so.2 => /l ib/ld-1 inux.so.2 (0x40000000) 

II suffit alors de copier les bonnes bibliotheques dans le repertoire /mnt/emb/1 ib. 

Cette methode est cependant tres fastidieuse et il est preferable d'utiliser pour cela le 
script mkl i bs . sh. Issu du projet DEBIAN (http://www.debian.org), ce petit script tres pra- 
tique (seulement 800 lignes de script, largement commentees) permet d' analyser une 
liste de fichiers executables, d'extraire les dependances par rapport aux bibliotheques 
partagees, puis de copier automatiquement ces bibliotheques sur le repertoire de votre 
choix. Dans notre cas, il suffit de faire : 

# cd /mnt/emb 

# mklibs.sh -v -d /mnt/emb/1 ib bin/* sbin/* 
Initializing data objects... done. 
Constructing dependency graph... (LALNLALA) done. 
Eliminating cycles... () done. 

No pic archive for library 1 ibdl -2. 2. 4. so found, falling back to simple copy. 
No pic archive for library 1 ibtermcap.so.2. 0.8 found, falling back to simple copy. 
No pic archive for library 1 ibc-2.2.4.so found, falling back to simple copy. 

Miraculeusement, les bibliotheques necessaires apparaissent dans le repertoire /mnt/emb/1 ib : 

# Is -1 /mnt/emb/1 ib/ 
total 1376 

88188 mar 22 07:11 ld-2.2.4.so 

11 mar 22 07:11 ld-1 inux.so.2 -> ld-2.2.4.so 

1282588 mar 22 07:11 1 i bc-2 . 2 .4 . so 

13 mar 22 07:11 libc.so.6 -> 1 i bc-2 . 2 . 4. so 
9828 mar 22 07:11 1 ibdl -2. 2. 4. so 

14 mar 22 07:11 libdl.so.2 -> 1 ibdl -2. 2. 4. so 
19 mar 22 07:11 libtermcap.so.2 -> 

11832 mar 22 07:11 1 ibtermcap.so.2. 0.8 

Lorsque vous ajouterez de nouveaux executables, il suffira de lancer de nouveau le script 
arm de mettre a jour les dependances. Le script est disponible sur le site de la distribution 
DEBIAN a l'adresse http://cvs.debian.org/boot-floppies/scripts/rootdisk. 

Dans le cas des nouvelles versions de la glibc (2.3 et superieure), il est preferable d'utiliser 
la nouvelle version de mkl ibs qui n'est plus ecrite en langage de script shell mais 
en langage Python. Cette nouvelle version est disponible a l'adresse http://pack.ages/ 
debian.org/unstable/divel/interlibs.html. L'utilisation du programme est tres similaire : 

# mkl ibs -v -d ./lib bin/* sbin/* 
I: Using ld-1 inux.so.2 as dynamic linker. 
I: library reduction pass 1 
Objects: adduser 
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Object: bin/adduser 

323 symbols, 323 unresolved 

reducing libm.so.6 

Moving libm.so.6 to libm.so.6. 

Moving 1 ibcrypt .so. 1 to 1 ibcrypt.so.l. 

Moving libc.so.6 to libc.so.6. 

Moving ld-1 inux.so.2 to ld-1 inux.so.2. 

# 

Ce qui conduit au remplissage du repertoire 1 ib comme suit : 



# Is -1 lib 
















total 1496 
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Remplissage du repertoire /etc 

La simplicite etant un facteur important pour un systeme embarque, nous veillerons a ce 
que toute la configuration du systeme soit localisee dans ce repertoire ou un de ses sous- 
repertoires. Outre la clarte de la structure, cette methode a pour avantage de permettre la 
duplication rapide de la configuration d'un systeme en copiant quelques fichiers sur un 
support quelconque. Cette fonctionnalite peut etre tres avantageuse pour la phase 
d' industrialisation, de duplication de systeme ou bien de maintenance. 

La version minimale du repertoire /etc contient les fichiers suivants : 



# Is -1 /mnt/emb/etc 

total 16 

-rw-r--r-- 1 root root 

-rw-r--r-- 1 root root 

drwxr-xr-x 2 root root 

-rw-r--r-- 1 root root 



158 mar 22 07:39 fstab 

798 mar 22 07:39 inittab 

4096 mar 22 07:39 red 

1868 mar 22 07:39 termcap 



Le fichier i ni ttab contient la configuration du programme /sbi n/i ni t ; dans notre cas, 
il est reduit au strict minimum. 



This file describes how the I N IT process should set up 
the system in a certain run-level. 



# 

# inittab 

# 
# 

§ Default runleve 
id:S:initdefaul t: 



# System initialization (runs when system boots) 
si :S:sysinit:/etc/rc.d/rc.S 



# End of /etc/i ni ttab 
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Le point a" entree sysinit donne le chemin d'acces au script re . S d'initialisation du systeme. 

Remarque 

Le lecteur notera la simplification drastique du systeme de demarrage par rapport a la procedure des « niveaux 
d'execution » decrite au chapitre precedent. Le fait est qu'un systeme embarque demarre en general un petit 
nombre de services et que la complexity de la procedure standard n'est pas forcement la plus adaptee. 

Dans la suite de revolution de notre systeme, le fichier inittab sera enrichi de l'utilisa- 
tion classique du programme getty associe a un systeme d'authentification par nom 
d'utilisateur (ou login) et un mot de passe. 

Le fichier re . S est egalement reduit au strict minimum : 

#!/bin/sh 

# 

# /etc/rc.d/rc.S: System initialization script. 

PATH=/sbin:/bin 

# Start update, 
/sbin/update & 

# Remount the root filesystem in read-write mode 
echo "Remounting root device with read-write enabled." 
/bin/mount -w -n -o remount / 
if [ $? -gt ]; then 

echo 

echo "Attempt to remount root device as read-write failed !" 
echo "This is going to cause serious problems..." 
fi 

Le fichier rc.S doit egalement effacer le fichier /etc/mtab qui contient la liste des syste- 
mes de fichiers montes. 

On peut ensuite monter les systemes listes dans le fichier /etc/f stab. 

echo "Cleaning mtab. " 
/bin/rm -f /etc/mtab* 

# Mounting local fs from /etc/fstab 
echo "Mounting local filesystems. " 
/bin/mount -at nonfs 

Le fichier f stab contient la liste des montages du systeme : 

I/dev/hdb3 / ext3 defaults 1 1 

none /proc proc defaults 

Ces montages sont reduits au strict minimum, en l'occurrence la partition principale et le 
pseudo-systeme de fichier /proc decrit au chapitre 4. 

Le script re . S se termine pour 1' instant par le demarrage de l'interpreteur de commande. 
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# Shell 
H0ME=/root 
USER=root 
export HOME USER 
cd $H0ME 
/bin/sh 



Le fichier termcap contient la description des capacites des terminaux utilisables sur le 
systeme. Cette version reduite comprend uniquement la description de la console locale 
linux, ainsi que celle de l'eternel vtlOO. Ce fichier est utilise par la libtermcap, elle- 
meme utilisee par bash. 

Rappel 

Linux utilise le systeme termcap (ou terminfo) derive d'Unix. Ce systeme a la fois simple et intelligent permet 
d'utiliser n'importe quel type de terminal - en mode texte - sans modifier les applications, et ce en definissant 
simplement les capacites (capabilities) du terminal dans la configuration du systeme. 



Creation d'un noyau adapte 



Comme nous l'avons vu au debut de ce chapitre, les noyaux livres avec les distributions 
standards sont largement surdimensionnes pour une utilisation en embarque. Rappelons 
que les modules livres avec le noyau standard de la Red Hat 7.2 occupent environ 25 Mo, 
30 Mo dans les dernieres versions, sans compter la partie statique qui occupe environ 
800 Ko en version compressee. Le noyau que nous utiliserons occupera environ 600 Ko 
pour la partie statique et seulement quelques dizaines de kilo-octets pour les modules, si 
ceux-ci sont utilises. 

La compilation d'un noyau Linux a ete longuement expliquee au chapitre 4. Concernant 
les sources a utiliser, le choix suivant s'offre a nous : 

• utiliser les sources du noyau a partir du package RPM (.src.rpm) fourni sur la distribu- 
tion Red Hat ; 

• utiliser les sources officiels du noyau a partir de la version standard disponible sur le 
site ftp.kernel.org. 

Dans le cas present, nous aurons tendance a recourir a la seconde solution, principale- 
ment parce que le noyau officiel offre systematiquement la derniere version a jour, et ce 
pour toutes les architectures. 

Le principal travail d' optimisation du noyau consistera en la comprehension des diverses 
options de ce dernier au travers des procedures make menuconf ig ou make xconf ig decri- 
tes precedemment. Ensuite, Ton s'attachera a elaguer les options valides pour ne conser- 
ver que celles specifiquement utilisees pour notre systeme. Les principales options 
decrites sont celles dont l'utilisation peut generer un surcout de taille ou de temps de 
demarrage du systeme. 
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Au moment de l'ecriture de la mise a jour de cet ouvrage se pose le probleme du choix 
entre le noyau 2.4 et le noyau 2.6. Le saut technologique n'est cependant pas si grand que 
cela et une distribution concue pour le noyau 2.4 pourra etre facilement adaptee au noyau 
2.6 sous reserve de mise a jour de quelques composants comme le paquetage moduti 1 s 
deja cite precedemment. Si Ton regarde le cote technique interne du noyau 2.6, les diffe- 
rences sont cependant notables et nous citerons : 

• 1' integration de la fonctionnalite de noyau preemptif que nous expliciterons au 
chapitre 9 ; 

• une meilleure integration avec le projet uClinux permettant le support des processeurs 
dans MMU ; 

• le support materiel encore ameliore en particulier sur les peripheriques recents comme 
l'USB ou les nouveaux peripheriques audio via ALSA ; 

• le modele de peripherique unifie et 1' utilisation du systeme de fichiers /sys (de type 
sysfs) permettant de visualiser l'arbre des peripheriques controles par le noyau ; 

• 1' amelioration du support multithread avec l'utilisation de NPTL (pour Native POSIX 
Thread Library) ; 

• la fonction d'hyperthreading permettant de gerer certains processeurs (comme les P4) 
de maniere virtuelle. 

Des documents tres complets concernant les nouvelles fonctionnalites du noyau 2.6 sont 
bien entendu disponibles sur Internet. Nous pouvons entre autres citer 1' article « Wonder- 
ful world of Linux 2.6 » par Joseph Pranevich (Jpranevich@kniggit.net) disponible a 
l'adresse http://www.kniggit.net/wwol26.html. Une traduction francaise de l'article est dis- 
ponible a l'adresse http://dsoulayrol.free.fr/articles/wonderful_2. 6. html. 

En resume, nous pouvons dire que face au choix entre le noyau 2.4 et le noyau 2.6, l'uti- 
lisateur pourra avoir 1' attitude suivante : 

• La migration vers 2.6 ne s' impose pas lorsqu'un systeme existant fonctionne correcte- 
ment et que Ton n'ajoute pas de nouveaux peripheriques ou protocoles qui necessite- 
raient un portage regressif (ou backport) vers le noyau 2.4. 

• Dans le cas d'un nouveau projet, l'utilisation du 2.6 est conseillee car certains projets 
comme RTAI (couche temps reel dur pour Linux etudiee au chapitre 9) utilisent le 
noyau 2.6 comme version de reference. II conviendra cependant de verifier que le sup- 
port des peripheriques materiels sur 2.6 est au meme niveau que sur 2.4 mais la ten- 
dance va dans ce sens. 

Le support des modules 

Le support correspond a l'entree Loadable module support. Dans le cas d'un systeme de 
petite taille, on peut envisager de ne pas utiliser de modules et done de limiter le noyau a 
sa composante statique. Ce choix peut etre motive par des contraintes de securite, en par- 
ticulier pour empecher l'ajout dynamique de fonctionnalites au noyau. La suppression 
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des modules permet egalement de simplifier la structure du systeme de par l'absence du 
repertoire /lib/modules. 

Dans la majorite des cas, il est cependant recommande de valider le support des modules 
- ainsi que celui de kmod - afin de conserver la compatibilite fonctionnelle avec les syste- 
mes Linux classiques, et aussi de se reserver la possibilite de mise a jour d'un pilote sans 
modifier la partie statique du noyau. Si le support des modules est conserve, il est recom- 
mande de valider dans la mesure du possible les options du noyau sous forme de modu- 
les, et ce en cochant 1' option M au lieu de Y. Certaines fonctions comme le support de 
disque dur ou le systeme de fichier principal devront cependant etre validees dans la par- 
tie statique du noyau. 

On pourra egalement ajouter les commandes systeme correspondant a la manipulation 
des modules dans l'espace utilisateur meme si cela n'est pas indispensable au niveau de 
la cible. 



[root@l oca! host 


1 inux 


-2.4]# Is - 


1 /sbin/insmod 
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/sbin/insmod 




[root@localhost 


1 inux 


-2.4]# Is - 


1 /sbin/lsmod 
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/sbin/lsmod -> 


insmod 


[root@localhost 


1 inux 


-2.4]# Is - 


1 /sbin/rmmod 
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/sbin/rmmod -> 


insmod 


[root@localhost 


1 inux 


-2.4]# Is - 


1 /sbin/modprobe 
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/sbin/modprobe 


-> insmod 


[root@localhost 


1 inux 


■2.4]# Is - 


1 /sbin/depmod 
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/sbin/depmod 





Le type de processeur 

Le choix du type de processeur a habituellement assez peu d'importance dans le cas de 
systemes classiques, meme si cela peut influer sur les performances de la machine. Le 
cas des systemes embarques est different car ils sont souvent bases sur des processeurs 
moins puissants (compatibles Pentium ou 486), et il est done indispensable de specifier le 
type de processeur sous peine de ne pouvoir executer le noyau. Les processeurs AMD de 
type Duron devront aussi etre specifies de la meme maniere. 

Attention 

Certaines architectures anciennes ne fonctionnent pas - ou mal - avec un noyau 2.4, et ce bien qu'elles soient 
annoncees compatibles 486. II est done important de verifier la compatibilite du noyau Linux aupres du fournisseur 
de processeur ou bien de carte. On pourra le cas echeant se rabattre sur un noyau plus ancien (2.2) mais cela 
peut entrainer des problemes d'evolutivite, en particulier concernant la disponibilite de pilotes de peripheriques. 



Les peripheriques en mode bloc 

Cette denomination concerne tout ce qui correspond a la memoire de masse (disquette, 
disques durs, interfaces SCSI ou autres interfaces specifiques). Les entrees correspon- 
dantes dans le menu de configuration du noyau sont Block devices, Memory Technology 
Devices (MTD), ATA/IDE/MFM/RLL et SCSI. 
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Le menu Block devices correspond a la validation de divers peripheriques speciaux 
comme ceux pilotes par le port parallele. La plupart de ces options devront etre invali- 
dees dans la majorite des cas. Notez cependant que la fonction de disque memoire (RAM 
disk) est validee par ce menu. Si vous desirez utiliser les techniques de RAM disk decri- 
tes plus avant dans l'ouvrage, vous devrez obligatoirement valider cette option. La vali- 
dation du support des disquettes est egalement tres utile car elle permettra de demarrer le 
noyau ou bien de faire des transferts de fichiers, par exemple en utilisant la commande 
tar directement sur le nom de device associe a la disquette. 

tar xvf /dev/fdO 

II faut egalement noter que le pilote de peripherique fourni par le constructeur M-Systems 
pour les flashes DiskOnChip est constitue d'un « patch » du noyau qui ajoutera 1' entree 
suivant dans le menu Block devices : 



♦ y 


■v m 


v " 


M- Systems DOC device support 


Help | 



Figure 5-4 

Configuration du support DiskOnChip. 

L' entree Loopback device support permet de configurer un device special tres utilise dans 
le monde Linux. II correspond aux entrees /dev/1 oopx (x variant de a 9) et permet de 
monter une image d'un systeme de fichier exactement comme Ton monterait le systeme 
de fichiers lui-meme. Par exemple, si vous disposez d'un fichier .iso correspondant a une 
image a graver sur CD-Rom, on pourra utiliser la commande : 

mount -t iso9660 -o loop mon_image.iso /mnt/cdrom 

Cette fonctionnalite sera egalement tres utile pour les images CRAMFS citees plus has. 

Le menu MTD concerne les memoires flash ne disposant pas d'interfaces IDE. Notons 
que le noyau Linux supporte egalement la majorite des peripheriques DiskOnChip a 
travers 1' interface MTD, ce qui peut avantageusement remplacer le pilote fourni par M- 
Systems. Ce menu permet egalement de valider 1' utilisation du systeme de fichier JFFS2 
(Jounalling Flash Filesystem, version 2) dont nous parlerons plus has. 



Attention 

Le pilote MTD ne fonctionne pas pour I'instant sur la derniere generation de flash « Millenium Plus » developpee 
par M-Systems. 



Le menu ATA/IDE/MFM/RLL est tres souvent utilise car il concerne les peripheriques 
IDE qui representent aujourd'hui l'interface disque la plus utilisee, particulierement dans 
le monde x86. Comme nous l'avons dit dans le chapitre 3 concernant les choix materiels, 
l'utilisation de peripheriques IDE est tres avantageuse car elle evite l'ajout de pilotes spe- 
ciaux et permet de manipuler plus facilement ces peripheriques dans le monde des PC 
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classiques. Ce choix a tout de meme quelques inconvenients, en particulier au niveau du 
cout mais aussi au niveau du temps de demarrage du systeme car la detection des peri- 
pheriques sur le bus IDE prendra souvent plus de temps que pour une flash non-IDE. Le 
support des disques IDE devra done etre valide, et ce dans la partie statique du noyau, 
afin de permettre l'acces au disque au moment du boot. La validation du support des dif- 
ferents chipsets devra etre adaptee en fonction de votre materiel. 

La partie SCSI est le plus souvent invalidee car les systemes de petite taille utilisent rare- 
ment ce type d'interface. 

La configuration reseau 

D'apres les statistiques decrites au chapitre 2, 16 % des utilisateurs choisissent Linux 
pour son excellent support reseau, ce qui represente a peine moins que le critere de dis- 
ponibilite des sources (20 %), l'absence de cout de licence (19 %) ou la robustesse 
(18 %). Tout cela pour dire que la majorite des applications embarquees sous Linux utili- 
seront le reseau et que sa configuration est done un point sensible. La configuration est 
divisee en trois parties : 

• les protocoles ; 

• les options de fonctionnement ; 

• les adaptateurs materiels (cartes). 

Les deux premiers points sont accessibles au travers du menu Networking options. La 
configuration des cartes est accessible par le menu Network devices. Une configuration 
embarquee prendra soin d'inhiber le support de tous les protocoles non utilises (Apple- 
Talk, IPX, DECnet). Pour le protocole TCP/IP, on pourra invalider les options non utili- 
sees comme Valiasing, le support de firewalling, le multicast ou le tunnelling. En 
revanche, Ton n'oubliera pas de valider le support du protocole PPP {Point to Point Pro- 
tocol) si l'equipement doit etre connecte a un reseau de type IP via une connexion 
modem ou ADSL. 

Le choix de l'adaptateur reseau se fera egalement en fonction des architectures materiel- 
les possibles. Si les cartes (ou la carte) sont validees dans la partie statique, elles seront 
automatiquement detectees au demarrage du noyau et ce avant 1' initialisation du reseau. 
Si le support est valide sous forme de module, alors ce dernier sera charge par kmod au 
moment de 1' initialisation du reseau a condition que la configuration soit indiquee dans le 
fichier /etc/modul es . conf pour 2.4 ou /etc/modprobe . conf pour 2.6. 

| alias ethO eeprolOO 

Les systemes de fichiers 

Comme nous l'avons dit precedemment, le systeme de fichiers constitue un peripherique 
virtuel qui sera pilote de la meme maniere qu'un peripherique materiel. On parle alors de 
pilote et done de support de tel ou tel systeme de fichiers. Les distributions classiques 
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valident le support pour les formats communement utilises sur les PC classiques en plus 
des systemes de fichiers natifs de Linux. En 1' occurrence, les formats FAT, VFAT (Win- 
dows) et ISO9660 (CD-Rom) seront systematiquement disponibles. 

Dans le cas d'un systeme embarque, on pourra valider uniquement le support ext3 dans 
le cas ou Ton utilise un disque muni d'une flash de type IDE, ou bien ne rien valider du 
tout si Ton utilise une flash non-IDE directement pilotee par la couche MTD. Le systeme 
de fichiers pourra alors etre de type JFFS2. Le menu contient egalement la validation du 
systeme de fichier CRAMFS (Compressed RAM File System), permettant de creer une 
image compressee d'un repertoire. L image pourra ensuite etre montee et utilisee avec les 
restrictions que nous expliciterons plus tard. 

Les peripheriques en mode caractere 

Ce type de peripherique est le plus frequent. Le type « mode caractere » indique que Ton 
peut dialoguer avec le peripherique au niveau de 1' octet contrairement aux peripheriques 
en mode bloc avec lesquels on n'echange que des blocs de donnees, par exemple 2048 
octets pour les lecteurs de CD-Rom. 

Ces peripheriques incluent : 

• les ports series standards ou cartes dites « multi-voies », 

• les ports paralleles, 

• les peripheriques de pointage (souris ou equivalent), 

• les pseudo-terminaux de type System V (Unix98 ptys), 

• les consoles virtuelles Linux, 

• le support du bus 12 C. 

Definitions 

Linux utilise les pseudo-terminaux de type BSD (Berkeley Software Distribution) qui correspondent aux entrees 
ttyxx et ptyxx du repertoire /dev. Les versions recentes de Linux qui utilisent la glibc-2.1 permettent 
cependant de se servir des pseudo-terminaux herites de System V. Lorsqu'un processus desire obtenir un 
pseudo-terminal, il accede au nceud /dev/ptmx et le pseudo-terminal alloue sera disponible en tant que / 
dev/pts/numero, equivalent au /dev/ttyp2 sous BSD. II sera done necessaire de creer le repertoire /dev/ 
pts ainsi que I'entree /dev/ptmx au moyende la commande mknod /dev/ptmx c 5 2. 

Ce menu contient egalement la validation du support de la console Linux sur le port serie : 



♦ y 


v - 


v n 


Support for console on serial port 


Help | 



Figure 5-5 

Support de console sur le port serie. 



Methodologie de creation d'un systeme Linux embarque 

^M~Deuxieme parte 

Par defaut, la console sera dirigee sur l'ecran local du systeme (la sortie VGA pour un PC 
classique). Dans un systeme embarque, cette sortie n'est pas toujours disponible et il est 
alors tres interessant de rediriger la console sur un terminal asynchrone de type emula- 
teur de terminal. La configuration d'une telle console est tres simple. Outre la validation 
de l'option susmentionnee, il est necessaire de specifier les parametres de la console au 
moment du demarrage a travers les options passees au noyau par LILO. La syntaxe a uti- 
liser est du type : 

LILO: linux console=ttySO 

En plus du port serie utilise - ici /dev/ttySO qui correspond au port COM1 du PC -, on 
peut specifier la vitesse, la parite et le nombre de bits de donnees. 

LILO: linux console=ttyS0,19200n8 

La valeur par defaut est 9600 bits/s, pas de parite, et 8 bits de donnees. 

L'ajout systematique d'une telle ligne se fera grace a la commande append de LILO dans 
le fichier /etc/1 i 1 o . conf decrit au chapitre precedent. 

append="consol e=ttyS0" 

Cette ligne sera ajoutee soit au niveau global (avant la premiere commande image), soit 
de maniere specifique sur une image donnee. Une documentation complete sur la confi- 
guration d'une console sur port serie est disponible dans le fichier Documentation/ 
serial-console.txt dans les sources du noyau Linux. 

Generation du noyau 

Lorsque les choix sont valides, la configuration du noyau est sauvegardee en activant l'option 
Save and Exit du menu principal. La generation du noyau se fait alors par un classique : 

| make dep; make clean; make bzlmage; make modules 

Si vous avez valide le support des modules, il faudra installer ceux-ci grace a la commande : 

make modules_instal 1 

qui installera l'arborescence /lib/modules/2.4.x sur votre systeme de developpement 
(x correspondant au niveau de patch du noyau). Le repertoire des modules devra ensuite 
etre copie dans l'arborescence du systeme embarque - soit /mnt/emb -, ainsi que le 
fichier /etc/modul es . conf. 



Remarque 

La copie devra etre faite en respectant les droits et attributs des fichiers initiaux. On peut pour cela utiliser les 
options -a et -r de la commande cp : 

cp -a -r source destination 
ou bien utiliser une combinaison des commandes f i nd et cpi o. 

cd source 

find . -print | cpio -pdv source 
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Test du systeme 

Le premier test du systeme peut s'effectuer en copiant l'image du noyau sur une dis- 
quette de demarrage. 

cd /usr/src/1 inux-2.4 

dd < arch/i386/boot/bzImage > /dev/fdO 

rdev /dev/fdO /dev/hdb3 

rdev -R /dev/fdO 1 

Si Ton considere que le systeme de fichier principal correspond a /dev/hdb3, lorsqu'on 
redemarre la machine en utilisant cette disquette de boot on doit obtenir : 

Linux version 2.4.18 (root@duron) (gcc version 2.96 20000731 (Red Hat Linux 7.1 
2.96-98)) #3 mar mar 26 18:18:08 CET 2002 
BIOS-provided physical RAM map: 



000000000009fc00 
OOOOOOOOOOOaOOOO 
0000000000100000 
0000000007ff0000 



(usable) 

(reserved) 

(reserved) 

(usable) 



0000000007ff8000 (ACPI data) 



0000000008000000 
OOOOOOOOfecOlOOO 
OOOOOOOOfeeOlOOO 
OOOOOOOOfffOOOOO 
0000000100000000 



(ACPI NVS) 
(reserved) 
(reserved) 
(reserved) 
(reserved) 



ro root=343 B00T_FILE=/boot/b 



BI0S-e820: 0000000000000000 

BI0S-e820: 000000000009fc00 

BI0S-e820: OOOOOOOOOOOf 0000 

BI0S-e820: 0000000000100000 

BI0S-e820: 0000000007f f 0000 

BI0S-e820: 0000000007f f 8000 

BI0S-e820: OOOOOOOOfecOOOOO 

BI0S-e820: OOOOOOOOfeeOOOOO 

BI0S-e820: OOOOOOOOffeeOOOO 

BI0S-e820: OOOOOOOOfffcOOOO 
On node totalpages: 32752 
zone(0) : 4096 pages, 
zoned) : 28656 pages . 
zone(2) : page. 

Kernel command line: auto B00T_IMAGE=2_4_18_emb_zb 
zlmage-2.4.18_emb_zb console=ttyS0 
Initializing CPU#0 
Detected 896.198 MHz processor. 
Console: colour VGA+ 80x25 
Calibrating delay loop... 1789.13 BogoMIPS 
Memory: 127016k/ 131008k available (919k kerne 
188k init, 0k highmem) 

Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) 
Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) 
Mount-cache hash table entries: 2048 (order: 2, 16384 bytes) 
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) 
Page-cache hash table entries: 32768 (order: 5, 131072 bytes) 
CPU: LI I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) 
CPU: L2 Cache: 64K (64 bytes/line) 
Intel machine check architecture supported. 
Intel machine check reporting enabled on CPU#0 . 
CPU: AMD Duron(tm) Processor stepping 01 
Enabling fast FPU save and restore... done. 
Checking 'hit' instruction... OK. 
Posix conformance testing by UNIFIX 
PCI: PCI BIOS revision 2.10 entry at OxfdbOl, last bus=l 



code, 3604k reserved, 225k data. 
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PCI: Using configuration type 1 

PCI: Probing PCI hardware 

Unknown bridge resource 0: assuming transparent 

PCI: Using IRQ router SIS [1039/0008] at 00:02.0 

Linux NET4.0 for Linux 2.4 

Based upon Swansea University Computer Society NET3.039 

Initializing RT netlink socket 

Starting kswapd 

Journalled Block Device driver loaded 

parportO: PC-style at 0x378 [PCSPP( )] 

pty: 256 Unix98 ptys configured 

Serial driver version 5.05c (2001-07-08) with MANY_P0RTS SHARE_IRQ SERIAL_PCI enabled 

ttySOO at 0x03f8 (irq = 4) is a 16550A 

ttySOl at 0x02f8 (irq = 3) is a 16550A 

IpO: using parportO (polling). 

Real Time Clock Driver vl.lOe 

block: 128 slots per queue, batch=32 

Uniform Multi-Platform E-IDE driver Revision: 6.31 

ide: Assuming 33MHz system bus speed for PI0 modes; override with idebus=xx 

SIS5513: IDE controller on PCI bus 00 dev 15 

SIS5513: chipset revision 208 

SIS5513: not 100% native mode: will probe irqs later 

ideO: BM-DMA at 0xff00-0xff07, BIOS settings: hda:DMA, hdb:DMA 
idel: BM-DMA at 0xff08-0xff0f , BIOS settings: hdc:DMA, hdd:DMA 
hda: WDC WD400BB-00CLB0, ATA DISK drive 
hdb: WDC AC2420H, ATA DISK drive 
hdc: CRD-8240B, ATAPI CD/DVD-ROM drive 
ideO at 0xlf0-0xlf7,0x3f6 on irq 14 
idel at 0x170-0x177,0x376 on irq 15 

hda: 78165360 sectors (40021 MB) w/2048KiB Cache, CHS=4865/255/63 
hdb: 830760 sectors (425 MB) w/128KiB Cache, CHS=989/15/56 
hdc: ATAPI 24X CD-ROM drive, 128kB Cache 
Uniform CD-ROM driver Revision: 3.12 
Partition check: 

hda: hdal hda2 hda3 

hdb: hdbl hdb2 hdb3 
Floppy drive(s): fdO is 1.44M 
FDC is a post-1991 82077 
PCI: Found IRQ 11 for device 00:0b. 

3c59x: Donald Becker and others, www.scyld.com/network/vortex.html 
00:0b. 0: 3Com PCI 3c905B Cyclone lOObaseTx at 0xd400. Vers LK1.1.16 
Linux video capture interface: vl.00 
NET4: Linux TCP/IP 1.0 for NET4.0 
IP Protocols: ICMP, UDP, TCP 

IP: routing cache hash table of 512 buckets, 4Kbytes 
TCP: Hash tables configured (established 8192 bind 8192) 
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. 
EXT3-fs: INFO: recovery required on readonly filesystem. 
EXT3-fs: write access will be enabled during recovery, 
kjournald starting. Commit interval 5 seconds 
EXT3-fs: recovery complete. 
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EXT3-fs: mounted filesystem with ordered data mode. 

VFS: Mounted root (ext3 filesystem) readonly. 

Freeing unused kernel memory: 188k freed 

I NIT : version 2.78 booting 

Remounting root device with read-write enabled. 

EXT3 FS 2.4-0.9.17, 10 Jan 2002 on ide0(3,67), internal journal 

Cleaning files. 

Mounting local filesystems. 

bash-2.05# 

Nous disposons d'ores et deja d'un systeme Linux fonctionnel et ce sur environ 2 Mo. 
Nous pourrons ensuite installer le chargeur de demarrage LILO comme decrit dans le 
chapitre 4. Pour cela, il faut tout d'abord copier le programme LILO sur la cible : 

cp /sbin/lilo /mnt/emb/sbin 

Si le systeme est installe sur un peripherique type CompactFlash IDE comme decrit au 
chapitre 3, celui-ci sera souvent maitre du deuxieme bus IDE, soit /dev/hdc. II faudra 
done configurer le fichier /etc/1 i 1 o . conf comme suit : 

boot=/dev/hdc 

read-only 

vga = normal 

# End LILO global section 

image = /boot/bzlmage 

root = /dev/hdcl 
label - linux 

Au niveau du repertoire /boot, il faudra copier le noyau en tant que fichier bz Image ainsi 
que les fichiers LILO, soit boot.b et map. Une fois que le systeme est demarre a partir 
de la disquette, il suffit de taper 1 i 1 o pour ecrire la configuration dans le secteur de 
demarrage. On peut aussi ecrire le secteur de demarrage depuis la partition de developpe- 
ment en utilisant 1' option - r de 1 i 1 o qui effectue un chroot avant de lire la configuration. 

/sbin/lilo -r /mnt/emb -v 

Le systeme est cependant relativement limite (seulement 4 commandes) et les deux cha- 
pitres suivants porteront sur 1' extension de ce systeme, en particulier au niveau des fonc- 
tionnalites reseau, inexistantes dans la version actuelle bien que l'adaptateur reseau soit 
detecte. 



Cas de I'utilisation de BusyBox 

Le composant BusyBox permet de remplacer une bonne partie des composants Linux 
habituels par des versions simplifiees. Lavantage est bien evidemment un gain de place 
lorsque l'empreinte memoire est limitee et que le systeme n'a pas besoin de toutes les 
fonctionnalites des commandes habituelles. De plus BusyBox est bien adapte a la compi- 
lation croisee et il simplifiera done la mise en place d'un environnement cible dans le cas 
de processeurs specifiques. 
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Les sources de BusyBox sont disponibles a l'adresse http://www.busybox.net. Une fois 
P archive extraite dans un repertoire de sources, on peut parameter la compilation de 
BusyBox en utilisant une syntaxe similaire a celle du noyau Linux, soit : 

$ make menuconfig 

Cette commande conduit a Paffichage de la fenetre suivante : 



|v'^,; -■■■■-■ - m., ■■■■:,■■; 




Figure 5-6 

Configuration de BusyBox avant compilation. 



Le nombre d' options est assez important et il n'est pas possible de les detailler ici. La 
documentation d' installation est assez succinte (le fichier INSTALL de la distribution) 
mais les menus de configuration sont clairs et il est aise d'arriver a une configuration 
fonctionnelle en choisissant les options par defaut. 

Apres configuration de Penvironnement, on peut compiler BusyBox en faisant : 

1$ make dep 
$ make 

On peut alors installer la distribution sur le repertoire cible, par exemple /mnt/emb. 

# make PREFIX=/mnt/emb install 

Cela a pour effet d'installer P executable busybox ainsi que les autres programmes qui 
constituent des liens symboliques vers le fichier /bin/busybox. 

Ilrwxrwxrwx 10 17 Apr 5 11:37 [ -> ../../bin/busybox 

lrwxrwxrwx 10 17 Apr 5 11:37 awk -> ../../bin/busybox 
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1 rwxrwxrwx 


1 





17 Apr 5 11:37 basename -> . ./. ./bin/busybox 


1 rwxrwxrwx 


1 





17 Apr 5 11:37 bunzip2 -> ../../bin/busybox 


1 rwxrwxrwx 


1 





17 Apr 5 11:37 bzcat -> ../../bin/busybox 



Dans notre cas, le repertoire /etc est reduit a sa plus simple expression : 

/ # cd /etc 

/etc # find . -print 

./init.d 

./init.d/rcS 

./fstab 

Le fichier rcS contient uniquement l'appel a la commande de montage mount : 

# cat init.d/rcS 
#! /bin/sh 

/bin/mount -a 

II est bien entendu necessaire d'utiliser mklibs pour remplir le repertoire /lib comme 
decrit precedemment. Dans notre cas, ce repertoire est simplifie puisque la commande 
busybox est la seule presente : 



/ # cd /lib/ 










/lib # Is -1 










-rwxr-xr-x 


1 





84936 Apr 


5 11:15 ld-linux.so.2 


-rw-r--r~- 


1 





1272092 Apr 


5 11:15 libc.so.6 


-rw-r--r-- 


1 





18588 Apr 


5 11:15 1 ibcrypt.so.l 


-rw-r--r~- 


1 





136004 Apr 


5 11:15 libm.so.6 


drwxr-xr-x 


3 





1024 Apr 


10 12:57 modules 



Au final, nous obtenons tres facilement un systeme complet qui contient un grand nom- 
bre de commandes Linux, y compris des utilitaires systeme de configuration de reseau ou 
de redemarrage. 

La trace qui suit decrit le demarrage d'un systeme base sur BusyBox et installe sur une 
simple cle USB. Le parametrage du noyau pour demarrer sur une cle USB sera decrit a la 
fin du chapitre 7. 



WAITING FOR A WHILE (1000) 

TO DETECT THE USB DISK 

scsiO : SCSI emulation for USB Mass Storage devices 
Vendor: USB 2.0 Model: FLASH DISK-SX Rev: 1.06 

Type: Direct-Access ANSI SCSI revision: 02 

SCSI device sda: 130656 512-byte hdwr sectors (67 MB) 
sda: assuming Write Enabled 
sda: assuming drive cache: write through 

sda: sdal sda2 
Attached scsi removable disk sda at scsiO, channel 0, id 0, lun 
Attached scsi generic sgO at scsiO, channel 0, id 0, lun 0, type 
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kjournald starting. Commit interval 5 seconds 
EXT3-fs: mounted filesystem with ordered data mode. 
VFS: Mounted root (ext3 filesystem) readonly. 
Freeing unused kernel memory: 188k freed 

Please press Enter to activate this console. 

BusyBox vl.00-rc3 (2005.04.05-10:33+0000) Built-in shell (ash) 
Enter 'help' for a list of built-in commands. 

/ # 



En resume 



Ce chapitre fondamental nous a appris a creer un systeme Linux minimal mais fonction- 
nel a partir de composants elementaires. Nous avons egalement vu que, de par la valida- 
tion par defaut d'un grand nombre d'options, les distributions classiques n'etaient pas 
adaptees a la creation directe d'un systeme embarque. 

Le nombre de bibliotheques partagees qu'il faut installer sur le systeme cible depend 
directement des programmes qui y sont installes. On peut deduire la liste de ces biblio- 
theques en utilisant le script mkl i bs . sh. 

De meme, on peut generer la majorite des entrees du repertoire /dev en utilisant la com- 
mande /dev/MAKEDEV. 

La configuration d'un noyau adapte demande certes une bonne connaissance des options 
dont il est dote, mais permet de reduire de maniere drastique l'espace utilise, particulie- 
rement au niveau des modules. 

Dans le cas d'un nouveau projet, l'utilisation du noyau 2.6 est preferable surtout si Ton 
desire utiliser des composants annexes dont le noyau de reference est souvent le 2.6. 

Dans le cas d'une distribution simple, l'utilisation de BusyBox permet de simplifier gran- 
dement la mise en place d'un systeme. 
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Comme nous Taverns rappele au chapitre precedent, la majorite des systemes Linux 
embarques necessitent des fonctionnalites reseau. Au niveau du noyau, la disponibilite du 
reseau implique les bons choix de configuration pour : 

• les protocoles, 

• les options de fonctionnement, 

• les adaptateurs materiels. 

Meme si le reseau n'est pas fonctionnel sur le systeme minimal construit au chapitre 5, 
on peut cependant remarquer dans la trace du demarrage du systeme qu'une bonne partie 
de la detection est deja effectuee, en particulier la detection de l'adaptateur et des protocoles 
supported. 

3c59x: Donald Becker and others, www.scyld.com/network/vortex.html 

00:0b. 0: 3Com PCI 3c905B Cyclone lOObaseTx at 0xd400. Vers LK1.1.16 

Linux video capture interface: vl.00 

NET4: Linux TCP/IP 1.0 for NET4.0 

IP Protocols: ICMP, UDP, TCP 

IP: routing cache hash table of 512 buckets, 4Kbytes 

TCP: Hash tables configured (established 8192 bind 8192) 

NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. 

La presence de ces messages n'indique cependant pas un reseau fonctionnel. Pour que le 
reseau soit totalement active, il est necessaire de completer 1' initialisation de 1' interface 
Ethernet et des tables de routage en utilisant les commandes ifconfig et route. 

Dans l'exemple presente plus haut, le support de l'adaptateur reseau (carte 3Com 3c905B) 
etait valide dans la partie statique. En cas de support par module, la detection de l'adap- 
tateur s'effectue au moment de l'initialisation de l'interface par i f conf i g. 
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On peut d'ores et deja enrichir notre systeme en y ajoutant ces deux commandes qui ne 
necessitent pas de nouvelles bibliotheques partagees. 

cp /sbin/ifconfig /sbin/route /mnt/emb/sbin 

Remarque 

Dans le cas de I'utilisation de BusyBox, les commandes ifconfig et route sont deja disponibles ainsi que 
d'autres utilitaires reseau. La suite du chapitre et en particulier I'ajout des bibliotheques NSS citees plus loin 
reste cependant toujours valable. 



La commande ifconfig 

La commande ifconfig permet de connaitre l'etat d'une interface reseau et de la confi- 
gurer. Utilisee en mode lecture, i f conf i g retournera la liste et la configuration des inter- 
faces du systeme. 

# ifconfig 

ethO Lien encap:Ethernet HWaddr 00 : 03 :47 : B6 : FA: EA 

inet adr: 192. 168.3.11 Beast : 192 . 168 . 3 . 255 Masque:255. 255. 255.0 

UP BROADCAST NOTRAILERS RUNNING MTU:1500 Metric:l 

RX packets:465 errors:0 dropped:0 overruns:0 frame:0 

TX packets:400 errors:0 dropped:0 overruns:0 carrier:0 

coll isions:0 

RX bytes:49726 (48.5 Kb) TX bytes:167486 (163.5 Kb) 

lo Lien encap:Boucle locale 

inet adr: 127.0.0.1 Masque:255. 0.0.0 

UP LOOPBACK RUNNING MTU:16436 Metric:l 

RX packets:20 errors:0 dropped:0 overruns:0 frame:0 

TX packets:20 errors:0 dropped:0 overruns:0 carrier:0 

col 1 isions:0 

RX bytes:1400 (1.3 Kb) TX bytes:1400 (1.3 Kb) 

L' interface 1 o ou interface locale est systematiquement utilisable si la couche TCP/IP du 
systeme est correctement initialisee, et ce meme si le systeme ne dispose pas d' autre 
adaptateur reseau. L'adresse IP associee a l'interface locale est toujours 127.0.0.1. 

Si Ton precise le nom de l'interface, ifconfig affichera uniquement la configuration de 
cette interface. 

# ifconfig ethO 

ethO Lien encap:Ethernet HWaddr 00 : 03 :47 : B6 : FA: EA 

inet adr: 192.168.3.11 Beast : 192 . 168. 3 . 255 Masque:255. 255. 255.0 

UP BROADCAST NOTRAILERS RUNNING MTU:1500 Metric:l 

RX packets:513 errors:0 dropped:0 overruns:0 frame:0 

TX packets:427 errors:0 dropped:0 overruns:0 carrier:0 

col 1 isions:49 

RX bytes:52927 (51.6 Kb) TX bytes:172257 (168.2 Kb) 

Les interfaces ethx, comme ethO ou ethl, correspondent respectivement au premier et au 
second adaptateur Ethernet detectes dans le systeme. Si une interface PPP (Point to Point 
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Protocol) est initialisee dans le systeme, l'interface correspondante sera pppO pour la 
premiere interface, pppl pour la deuxieme, et ainsi de suite. 

La commande ifconfig fait partie des commandes systeme essentielles et elle est done 
situee sur le repertoire /sbi n. De ce fait, elle n'est pas accessible directement a l'utilisateur 
non privilegie, sauf si ce dernier utilise le chemin d'acces complet de la commande. Pour 
un utilisateur non privilegie, la commande n'est bien entendu accessible que pour des 
operations de lecture de l'etat des interfaces et non pour des operations de configuration. 

[pierre@local host pierre]$ type ifconfig 
bash: type: ifconfig: not found 
[pierre@local host pierre]$ ifconfig 
bash: ifconfig: command not found 
[pierre@local host pierre]$ /sbin/ifconfig lo 
lo Lien encap:Boucle locale 

inet adr:127. 0.0.1 Masque:255. 0.0.0 

UP L00PBACK RUNNING MTU : 16436 Metric:l 

RX packets:8 errors:0 dropped:0 overruns:0 frame:0 

TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 

col 1 isions:0 

RX bytes:560 (560.0 b) TX bytes:560 (560.0 b) 

En mode configuration - done uniquement pour le super-utilisateur root -, la commande 
ifconfig est utilisee le plus souvent pour 1' initialisation des parametres suivants d'une 
interface reseau : 

• 1'adresseIP, 

• le masque du reseau ou netmask, 

• le masque de diffusion ou broadcast. 

Les deux derniers parametres peuvent etre en general calcules automatiquement en fonc- 
tion de l'adresse IP car celle-ci determine la classe d'adresse utilisee par le systeme. Le 
calcul sera effectue par le script d' initialisation du reseau lors de la procedure de demar- 
rage du systeme. 

Rappel 

Le systeme d'adressage IP (version 4) subdivise les adresses en sous-ensembles appeles classes. Sachant 
qu'une adresse IP est du type a.b.c.d, la classe est definie par la valeur a du premier element de l'adresse. Le 
tableau ci-apres donne la correspondance entre la valeur de a et les autres parametres. 



Tableau 6-1 . Affectation des classes de reseau 


Valeur de a 


Classe 


Masque diffusion 


Masque reseau 


Entre et 127 


A 


a.255.255.255 


255.0.0.0 


Entre 128 et 191 


B 


a.b.255.255 


255.255.0.0 


Entre 1 92 et 223 


C 


a.b.c.255 


255.255.255.0 


Superieur a 224 


D (reserve) 


a.b.c.255 


255.255.255.0 
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On peut done initialiser manuellement les interfaces 1 o et ethO de notre systeme en utili- 
sant les commandes suivantes, pour 1 o : 

/sbin/ifconfig lo 127.0.0.1 

et pour ethO : 

/sbin/ifconfig ethO 192.168.3.3 netmask 255.255.255.0 broadcast 192.168.3.255 

La commande route 

La commande route permet de manipuler les tables de routage IP du noyau Linux. Une 
table de routage decrit le chemin emprunte par un paquet IP partant du systeme courant 
et a destination d'une autre adresse ou groupe d'adresses. L'entree dans la table de rou- 
tage decrit une interface employee (par exemple, ethO) ainsi que la passerelle ou 
gateway a utiliser pour faire cheminer ces paquets. Comme pour la commande i f conf i g, 
il est possible a l'utilisateur non privilegie d'utiliser route pour connaitre les tables de 
routage du noyau. Sur une station classique connectee au reseau local, on obtient : 

$ /sbin/route -n 
Table de routage IP du noyau 
Destination Passerelle 

192.168.3.0 0.0.0.0 

127.0.0.0 0.0.0.0 

0.0.0.0 192.168.3.1 

Le resultat indique les tables de routage pour les interfaces Ethernet ethO et locales 1 o. 
La derniere ligne indique le routage par defaut sur la passerelle 192.168.3.1. Un resultat 
identique est obtenu en utilisant la commande netstat -nr. 

On peut done poursuivre l'initialisation de notre interface 1 o en faisant, en tant que super- 
utilisateur : 

/sbin/route add -net 127.0.0.0 netmask 255.0.0.0 dev lo 

ce qui initialise la table de routage pour les paquets transitant sur 1' interface locale. De 
meme, pour 1' interface ethO : 

/sbin/route add -net 192.168.3.0 netmask 255.255.255.0 dev ethO 

Le parametre passe a l'option -net indique la valeur du reseau. II correspond a la valeur 
du masque de diffusion en remplacant les valeurs 255 par 0. On pourrait egalement defi- 
nir une table de routage vers une adresse donnee en utilisant une option du type -host 
adresse_di stante. 

L' utilisation de la commande route -n en lecture permet de verifier la valeur des tables 
de routage. Notez que nous n'avons pas defini de passerelle, sachant que le test se limite 
pour l'instant a l'interface locale (lo) ou bien a un reseau Ethernet local (ethO). Pour 
ajouter une valeur de passerelle, on utilisera l'option gw de la commande route. En parti- 
culier, la ligne suivante indiquera que tous les paquets IP externes au reseau local devront 
etre routes par la passerelle 192 . 168 .3.1. 

/sbin/route add default gw 192.168.3.1 



Genmask 


Indie Metric Ref 


Use Iface 


255.255.255.0 


U 


ethO 


255.0.0.0 


U 


lo 


0.0.0.0 


UG 


ethO 
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Premier test des interfaces en ICMP 

On dispose d'une methode simple pour tester le reseau en utilisant la commande ping, 
laquelle permet d'envoyer des trames ICMP {Internet Control Message Protocol) vers 
une adresse IP donnee. Pour cela, il faut ajouter la commande ping sur la cible embar- 
quee. Ce programme utilise cependant une bibliotheque partagee supplemental qu'il 
faut egalement ajouter a la cible. 

# ldd /bin/ping 

libresolv.so.2 => /I ib/1 ibresol v.so.2 (0x4002d000) 
libc.so.6 => /lib/i686/libc.so.6 (Ox4003fOOO) 
/lib/ld-linux.so.2 => /I ib/ld-1 inux.so.2 (0x40000000) 

Pour ce faire, on peut soit executer de nouveau le script mkl i bs . sh comme decrit dans le 
chapitre precedent, soit ajouter la bibliotheque a la main en executant : 

cp -a /l ib/libresol v* /mnt/emb/lib 

On peut ensuite tester la connexion Ethernet sur le reseau local. 

bash-2.05# ping 192.168.3.1 

PING 192.168.3.1 (192.168.3.1) from 192.168.3.3 : 56(84) bytes of data. 

64 bytes from 192.168.3.1: icmp_seq=0 ttl-255 time=648 usee 

64 bytes from 192.168.3.1: icmp_seq=l ttl-255 time=4.825 msec 

64 bytes from 192.168.3.1: icmp_seq=2 ttl=255 time=356 usee 

— 192.168.3.1 ping statistics — 

3 packets transmitted, 3 packets received, 0% packet loss 
round-trip min/avg/max/mdev = 0.356/1.943/4.825/2.041 ms 

Si Ton ajoute une regie de routage par defaut, on peut tester remission de trames ICMP 
vers des machines de 1' Internet. 

bash-2.05# route add default gw 192.168.3.1 

bash-2.05# ping 213.56.52.14 

PING 213.56.52.14 (213.56.52.14) from 192.168.3.3 : 56(84) bytes of data. 

64 bytes from 213.56.52.14: icmp_seq=0 ttl=255 time=363 usee 

64 bytes from 213.56.52.14: icmp_seq=l ttl=255 time=375 usee 

— 213.56.52.14 ping statistics — 

2 packets transmitted, 2 packets received, 0% packet loss 
round-trip min/avg/max/mdev = 0.363/0.369/0.375/0.006 ms 



Test de services TCP 

Le test precedent ne permet pas de valider totalement 1' interface car les services classi- 
ques de type http, telnet ou ftp utilisent le protocole TCP (Transport Control Protocol) et 
non ICMP. Le probleme est le meme pour les services bases sur UDP (User Datagram 
Protocol) qui se situent au meme niveau que le protocole TCP. Si nous effectuons un test 
sur le service FTP - utilisant le protocole TCP sur le port numero 21 -, nous obtenons : 

Ibash-2.05# ftp 
ftp: ftp/tcp: unknown service 
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La liste des services TCP et UDP et les ports associes sont en effet definis dans le fichier 
/etc/services que nous devons done copier sur la cible. Nous copions egalement le 
fichier /etc/protocols qui donne la liste des protocoles IP associes a leurs numeros 
d'identification. 

(cp /etc/services /mnt/emb/etc 
cp /etc/protocols /mnt/emb/etc 

Helas, cette condition necessaire n'est pas suffisante et le service FTP n'est toujours pas 
fonctionnel : 



I 



bash-2.05# ftp 

ftp: ftp/tcp: unknown service 



La raison de ce dysfonctionnement est l'absence de configuration de la fonction NSS ou 
Name Service Switch. La NSS est une fonction de la glibc2 heritee du systeme Solaris de 
SUN Microsystems. Le but de la NSS est de pouvoir etendre de maniere dynamique les 
fonctions reseau de la glibc2 de maniere dynamique, en utilisant des bibliotheques char- 
gees au cours de l'execution du programme. Ces bibliotheques ne sont pas visibles avec 
la commande 1 dd et elles sont accessibles par les fonctions de type dl open. Avant l'appa- 
rition de la NSS et de la glibc2, la libc5 devait gerer de maniere statique toutes les fonc- 
tionnalites reseau ajoutees, comme la gestion des DNS (Domain Name Service) ou des NIS 
(Network Information Service). La NSS permet done a des contributeurs externes d'ajou- 
ter des services sans toucher au code de la glibc2, ce dernier gardant done une taille rai- 
sonnable, meme si la glibc2 est deja assez volumineuse. 

Les differents modules geres par la NSS sont identifies par un nom de service dans une 
base de donnees (networks, ethers, protocols, hosts, etc.). La methode de recherche est 
definie dans le fichier /etc/nsswi tch . conf . 

# /etc/nsswitch.conf 
# 

# Name Service Switch configuration file. 
# 

passwd: db files nis 

shadow: files 

group: db files nis 

hosts: files nisplus nis dns 

networks: nisplus [NOTFOUND=return] files 

ethers: nisplus [NOTFOUND=return] db files 

protocols: nisplus [NOTFOUND=return] db files 

rpc: nisplus [NOTFOUND=return] db files 

services: nisplus [NOTFOUND=return] db files 

Le mot-cle f 1 1 es indique que Ton utilisera une configuration statique definie dans un fichier 
de configuration, en general situe dans le repertoire /etc. De la meme maniere, n1 spl us 
indique que Ton recherchera l'information sur une base NIS+ si celle-ci est disponible. 
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Si Ton considere un service NOM, le code de gestion de ce dernier sera disponible dans 
un module libnss_NOM. Dans le cas de Linux qui gere les bibliotheques partagees, cela 
correspondra a une bibliotheque partagee du type 1 ibnss_N0M.so.2. Nous pouvons veri- 
fier cela sur un systeme Linux complet. 

# 

4 2001 /lib/libnss_compat-2.2.4.so 
1 17:05 /I ib/libnss_compat .so. 1 -> 

*» 1 ibnssl_compat-2.2.4.so 
1 17:05 /I ib/libnss_compat .so. 2 -> 

*» 1 ibnss_compat-2.2.4.so 
4 2001 /lib/libnss_dns-2.2.4.so 
1 17:05 /lib/libnss_dns.so.l -> 

* libnssl_dns-2.2.4.so 
1 17:05 /lib/libnss_dns.so.2 -> 

*• libnss_dns-2.2.4.so 
4 2001 /lib/libnss_files-2.2.4.so 
1 17:05 /lib/libnss_files.so.l -> 

*• libnssl_files-2.2.4.so 
1 17:05 /lib/libnss_files.so.2 -> 

*• 1ibnss_files-2.2.4.so 
4 2001 /lib/libnss_hesiod-2.2.4.so 
1 17:05 /lib/libnss_hesiod.so.2 -> 

* libnss_hesiod-2.2.4.so 
31 2001 /lib/libnss_ldap-2.2.4.so 

1 17:13 /lib/libnss_ldap.so.2 -> 

*• libnss_ldap-2.2.4.so 
4 2001 /lib/libnss_nis-2.2.4.so 
4 2001 /lib/libnss„nisplus-2.2.4.so 
1 17:05 /lib/libnss_nisplus.so.2 -> 

*» 1 ibnss_nispl us-2.2.4.so 
1 17:05 /lib/1 ibnss_ni s.so.l -> 

* libnssl_nis-2.2.4.so 
1 17:05 /lib/libnss_nis.so.2 -> 

*• libnss_nis-2.2.4.so 

Dans le cas ou le fichier /etc/nsswitch.conf serait absent, le service hosts utilisera par 
defaut Faeces dns, puis Faeces files. Si nous copions simplement la bibliotheque 1 i bnss_ 
f i 1 es . so . 2, nous avons maintenant acces au site distant par la commande ftp a condition 
d'utiliser les adresses IP numeriques. Nous copions egalement le fichier nsswi tch . conf . 

Icp /etc/nsswitch.conf /mnt/emb/etc 
cp -a /l ib/1 ibnss_files* /mnt/emb/lib 

Nous testons cela ensuite sur la cible. 

# ftp 

ftp> open 192.168.3.1 

Connected to 192.168.3.1 (192.168.3.1). 

220 ca-ol-bordeaux-9-14.abo.wanadoo.fr FTP server (Version wu-2.6.0(l) Fri Jun . 

Name (192.168.3.1): pierre 



Is -1 /li 


b/libnss_* 
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20 
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1 
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19 
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331 Password required for pierre. 

Password: 

230 User pierre logged in. 

Remote system type is UNIX. 

Using binary mode to transfer files. 

Nous pouvons maintenant renseigner le fichier de definition du DNS /etc/resol v . conf 
avec une adresse de serveur DNS valide. 

I it cat /etc/resol v. conf 
nameserver 62.161.120.17 

Mais cela ne fonctionne pas : 

I it ftp ftp. kernel .org 
ftp: ftp.kernel.org: Name or service not known 

On corrige cela en copiant la bibliotheque 1 i bnss_dns . so . 2 . 

cp -a /I ib/1 ibnss_dns* /mnt/emb/lib 

On peut alors poursuivre ce test sur la cible. 

it ftp ftp. kernel .org 

Connected to ftp.kernel.org (204.152.189.113). 

220 ProFTPD [ftp.kernel.org] 

Name (ftp.kernel.org): anonymous 

331 Anonymous login ok, send your complete email address as your password. 

Password: 

230- Welcome to the 

LINUX KERNEL ARCHIVES 
ftp. kernel .org 



Conclusion 

L'utilisation des bibliotheques libnss est fondamentale dans un environnement utilisant la glibc2. L'evolution de la 
cible vers de nouveaux services devra etre systematiquement accompagnee de I'installation des bibliotheques 
libnss associees. 



Scripts de configuration du reseau 

Pour les tests precedents, nous avons effectue la configuration du reseau directement 
dans la ligne de commande. Cette methode n'est bien entendu pas utilisable dans le cas 
d'un systeme embarque reel qui devra demarrer sans aucune action d'un operateur. Le 
principe utilise ici consiste a concentrer la configuration du reseau dans un seul fichier 
network situe sur le repertoire /etc/sysconf ig. Cette methode a le gros avantage de sim- 
plifier la structure du systeme mais aussi de permettre a un utilisateur depourvu d'exper- 
tise Linux de pouvoir configurer le reseau assez simplement. Un autre avantage, annexe, 
est la possibility de dupliquer la configuration d'un systeme en copiant un simple fichier. 
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Si nous reprenons la fin du script de demarrage /etc/ red/ re. S, nous trouvons les lignes 
suivantes : 

# Mount local fs from /etc/fstab 
echo "Mounting local filesystems. " 
/bin/mount -at nonfs 

§ Shell 
H0ME=/root 
USER=root 
export HOME USER 
cd $H0ME 
/bin/bash 

L' initialisation du reseau devra se faire juste avant le lancement de l'interpreteur de com- 
mande /bi n/sh. Dans notre cas, nous separerons 1' initialisation du reseau en deux phases : 

• 1' initialisation des interfaces reseau, comme effectue precedemment, 

• le lancement des services reseau si necessaire. 

Le second point concerne les programmes serveurs qui pourraient etre demarres sur la 
cible, par exemple des demons FTP, HTTP, Telnet ou NTP 



Definition 

Dans la terminologie Unix, un demon (issu de I'anglais daemon) est un programme lance en tache de fond et 
charge d'assurer un service. Les programmes serveurs FTPD et HTTPD (comme Apache) sont des exemples 
de programmes de ce type. 



La premiere phase d'initialisation du reseau correspond physiquement a un script /etc/ 
rc.d/rc.inetl. La phase de lancement des services correspond au script /etc/red/ 
re . i net2. Au niveau du script de demarrage, il suffit done d'ajouter les lignes : 

# Network 

/etc/rc.d/rc.inetl start 
/etc/rc.d/rc.inet2 start 

avant le lancement du shell. 

Les scripts sont ecrits en langage shell et nous utilisons la notion de variable d'environ- 
nement Unix pour centraliser la configuration du reseau dans /etc/sysconfig/network. 
Le fichier a 1' allure suivante : 

# Network configuration 
HOSTNAME=embtest 
DOMAINNAME=localdomain 
DEVICE=ethO 
IPADDR=192.168.3.3 
GATEWAY=192. 168.3.1 
NETMASK=255. 255. 255.0 
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NETW0RK=192.168.3.0 
BR0ADCAST=192.168.3.0 
DNS1=62. 161.120. 17 

DNS2= 

Au niveau du script re . i netl, le contenu du fichier precedent est « evalue » au debut du 
script. 

#!/b1n/sh 

# Variables globales 
. /etc/sysconfig/variables 

# Reseau 
. SNETCFG 

Le fichier variables contient des variables d'environnement communes a tous les 
richiers de configuration. 

BASE=/etc/sysconfig 

NETCFG=$BASE/network 

GENCFG=$BASE/general 

H0STS=/etc/hosts 

RESOLV=/etc/resolv.conf 

DAEM0NS= 

Bien que le systeme n' utilise pas le systeme de niveau d' execution (run level), le script 
est prevu pour demarrer les interfaces reseau, en passant le parametre start, ou bien pour 
les arreter en passant le parametre stop. On utilise pour cela un simple test case/esac au 
niveau du script. 

case $1 in 

start) 

# Demarrage du reseau 

stop) 

# Arret du reseau 

*) echo "Usage: re. i netl {start | stop} " 

exit 1 

esac 
La partie demarrage du script re. i netl comprend les phases suivantes. 



Initialisation de I'interface locale 

Cette phase reprend simplement les lignes de commandes utilisees pour les tests. 

# Loopback 

/sbin/ifconfig lo 127.0.0.1 

/sbin/route add -net 127.0.0.0 netmask 255.0.0.0 dev lo 

/sbin/ifconfig lo up 
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Initialisation de I'interface Ethernet 

La valeur peut etre obtenue soit directement dans le fichier network (IPADDR), soit en 
interrogeant un serveur DHCP (Domain Host Control Protocol). Dans notre cas, nous 
utilisons le client DHCP dhcpcd fourni sur la distribution Red Hat 7.2. Cette methode 
permet de recuperer automatiquement les parametres reseau pour la connexion Ethernet 
sous forme d'un fichier /etc/dhcpc/dhcpcd-ethO.info, si ethO est le nom de I'interface 
Ethernet. 



IPADDR=192.168.3.4 

NETMASK>255. 255. 255.0 

NETW0RK=192. 168.3.0 

BR0ADCAST=192.168.3.255 

GATEWAY=192. 168.3.1 

D0MAIN=localdomain 

DNS=62.161.120.17 

DHCPSID=127. 0.0.1 

DHCPGIADDR=0. 0.0.0 

DHCPSIADDR=192.168.3.1 

DHCPCHADDR=00:A0:24:78:34:6A 

DHCPSHADDR=00:60:97:67:4B:79 

DHCPSNAME= 

LEASETIME=600 

RENEWALTIME=300 

REBINDTIME=525 



Pour le fichier /etc/sysconf i g/network, on declare une connexion DHCP en n'initialisant 
aucune variable a 1' exception du nom de I'interface Ethernet (DEVICE=ethO). On en deduit 
le code du script, qui attend l'ecriture du fichier dhcpcd-ethO.info. 



if [ 



-a "$IPADDR" 



]; then 



'SDEVICE" != 
# DHCP 

rm -rf /etc/dhcpc/* /var/run/dhcpcd-${DEVICE} .pid 
DHCPFILE=/etc/dhcpc/dhcpcd-${ DEVICE}. info 
DHCP_0K= 

echo -n "Using DHCP for ${DEVICE}" 

/sbin/dhcpcd -n -H ${DEVICE} 

for i in 1 2 3 4 5 6 7 8 9 10 11 12 

do 

echo -n "." 

if [ -r ${DHCPFILE} ]; then 
DHCP_0K=true 
D0MAINNAME=$D0MAIN 
break 



iRESOLV 



fi 

usleep 2000000 



done 
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if [ "$DHCP_0K" = "" ]; then 

echo "ERROR !" 
else 

echo "OK" 

. ${DHCPFILE) 

DNS1=${DNS} 

D0MAINNAME=${DOMAIN} 
fi 

L' initialisation de l'interface, du serveur de nom et du routage par defaut est entierement 
effectuee par le demon dhcpcd. 

Dans le cas d'une adresse IP statique, on calcule automatiquement les valeurs de reseau, 
masque de reseau et masque de diffusion (NETWORK, NETMASK et BROADCAST), si celles-ci ne 
sont pas definies dans le fichier network. Les valeurs sont calculees en respectant les 
regies decrites dans le tableau 6-1. L'extrait de code ci-apres donne le calcul effectue en 
cas de classe A : 

# Static IP 

echo "# DNS list" > $RES0LV 

if [ "SIPADDR" != "" ]; then 

# Network, Netmask & broadcast generated from IPADDR 
set 'echo ${IPADDR} | sed -e "s/\./ /g"* 
if [ $1 -ge -a $1 -le 127 ] 
then 

# Class A 

if [ "SNETWORK" = "" ]; then 

NETW0RK=${ 11.0.0.0 
fi 
if [ "SNETMASK" = "" ]; then 

NETMASK=255. 0.0.0 
fi 

if [ "SBROADCAST" = "" ]; then 
BR0ADCAST=${1} .255.255.255 
fi 
elif [ $1 -ge 128 -a $1 -le 191 ] 

fi 

Ensuite, l'interface est initialisee au moyen de la commande ifconfig et les regies de 
routage, dont le routage par defaut, sont mises en place grace a la commande route. 

# Ethernet 

/sbin/ifconfig $f DEVICE} ${IPADDR} broadcast ${BROADCAST} netmask ${NET) 
/sbin/route add -net ${NETW0RK} netmask ${NETMASK} ${DEVICE) 
/sbin/ifconfig ${DEVICE) up 

# external addresses 
if [ "$GATEWAY" != "" ] 
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I then 
/sbin/route add default gw ${GATEWAY} 

La fin de l'initialisation se resume au calcul dynamique du fichier /etc/resol v . conf afin 
d'affecter les adresses des serveurs DNS primaries et secondaires : 

# DNS 

if [ "$DNS1" !- "" ]; then 

echo "nameserver $DNS1" » SRESOLV 

fi 

if [ "$DNS2" !- "" ]; then 

echo "nameserver $DNS2" » $RES0LV 
fi 



Calcul du nom du systeme et creation du fichier hosts 

La fin du script initialise le nom du systeme grace a la commande hostname. Par defaut, 
le nomdu systeme est local host, local domain. 

# Set system name 
if [ "SDOMAINNAME" != "" ]; then 

D0M=".${D0MAINNAME}" 

fi 

if [ "SHOSTNAME" !- "" ]; then 

/bin/hostname ${H0STNAME}${D0M) 
else 

/bin/hostname localhost${DOM} 

fi 

Enfin, le fichier /etc/hosts est cree dynamiquement a partir d'un prototype /etc/ 
hosts. ref : 

# /etc/hosts file 
if [ "SDEVICE" != "" ]; then 

if [ "SDOMAINNAME" = "" ]; then 
DOMAINNAME=" some. where" 

fi 

cat ${H0STS}.ref | sed -e "s/IPADDR/${IPADDR}/g" -e "s/HOSTNAME/${HOSTNAME)" 
else 

cat ${H0STS}.ref | grep -v IPADDR > SHOSTS 
fi 

La partie arret (stop) du script rc.inetl se resume simplement aux lignes suivantes : 

stop) 

/sbin/ifconfig lo down 
/sbin/ifconfig ${DEVICE} down 
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Le script re . i net2 est beaucoup plus simple car il se borne a explorer la liste definie dans 
la variable DAEMONS : 

#!/bin/sh 

. /etc/sysconfig/variables 
. IMETCFG 

case $1 in 

start) 

echo -n "Starting daemons: " 

for i in SDAEMONS 
do 

if [ -x /sbin/$i ] ; then 
echo -n "$i " 
/sbin/$i & 
fi 
done 
echo "";; 

stop) 

echo -n "Stopping daemons: " 

for i in SDAEMONS 

do 

if [ -x / s b i n / $ i ]; then 
echo -n "$i " 
/bin/kill all $i 

fi 
done 
echo "";; 



echo "Usage: rc.inet2 {start | stop}" 
exit 1; ; 
esac 

Si la variable DAEMONS n'est pas definie, le script n'aura alors aucun effet. Notez que le 
script suppose que les demons soient localises sur le repertoire /sbin. 

Au total, la taille des scripts re . i netl et re . 1 net2 est inferieure a 200 lignes de code, les 
commentaires compris. Meme si la meme complexite de configuration n'est pas geree, 
on peut etre tente de comparer avec les plusieurs centaines de lignes ou plus des scripts 
d'initialisation reseau dans une distribution classique. 
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Mise en place de services reseau 

Sous Linux, on peut definir un service reseau de deux facons : 

• En utilisant un programme demon autonome, repondant a l'adresse IP du systeme sur 
un port donne. On parle alors de programme stand-alone. 

• En utilisant le principe du « super-demon » inetd, ce dernier permettant de mettre en 
place et d'administrer plus facilement un service reseau. 

En pratique, un bon nombre de services reseau utilisent inetd ou xinetd. Les services 
comme Apache qui utilisent le mode stand-alone le font pour des raisons de performan- 
ces car le passage par le super-demon reduit l'efficacite du service dans le cas d'un nom- 
bre important de connexions simultanees. 

Dans le cas present, nous allons mettre en place un service interne a xinetd, en l'occur- 
rence le service rdate, defini dans le document RFC-868, et qui permet d'obtenir a 
distance la date d'un systeme. 

I# rdate 192.168.3.3 
[192.168.3.3] Mon Apr 8 19:05:15 2002 

Nous devons tout d'abord installer le super-demon xi netd, ainsi que les bibliotheques et 
fichiers de configuration associes. Le programme xinetd utilise quelques bibliotheques 
partagees supplementaires que nous devrons copier dans le repertoire /l i b. 

# ldd /usr/sbin/xinetd 

libnsl.so.l => /lib/libnsl.so.l (0x4002d000) 
libm.so.6 => /l i b/i 686/1 ibm.so.6 (0x40043000) 
libcrypt.so.l => /l ib/1 ibcrypt.so.l (0x40066000) 
libc.so.6 => /lib/i686/libc.so.6 (0x40093000) 
/lib/ld-linux.so.2 => /I ib/ld-1 inux.so.2 (0x40000000) 

Soit libnsl, libcrypt et libm. 

II faut ensuite copier le fichier de configuration /etc/xi netd . conf et certains fichiers du 
repertoire /etc/xi netd . d en fonction des services que Ton veut installer. Chaque service 
est defini par un fichier de configuration dans xi netd . d. 



§ Is -1 /etc 


/xinetd.d 




total 64 








-rw-r--r~- 


1 


root 


root 


-rw-r--r~- 


1 


root 


root 


-rw-r--r~- 


1 


root 


root 


-rw-r--r-- 


1 


root 


root 


-rw-r--r-- 


1 


root 


root 


-rw-r--r-- 


1 


root 


root 


-rw-r--r-- 


1 


root 


root 


-rw-r--r-- 


1 


root 


root 


-rw-r--r-- 


1 


root 


root 


-rw-r--r-- 


1 


root 


root 



295 mar 


3 


23 


59 


chargen 


295 mar 


3 


23 


59 


daytime 


287 mar 


3 


23 


59 


echo 


306 mar 


3 


23 


59 


echo-udp 


343 mar 


3 


23 


59 


1 inuxconf-web 


317 mar 


3 


23 


59 


rsync 


406 mar 


3 


23 


59 


sgi_fam 


302 mar 


3 


23 


59 


telnet 


318 mar 


3 


23 


59 


time 



314 mar 3 23:59 time-udp 
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Les fichiers a copier pour rdate sont time et time-udp. 

Le programme xinetd necessite egalement la presence d'une liste d'utilisateurs /etc/ 
passwd car il fait reference a l'utilisateur root dans ses fichiers de configuration. La mise 
en place de l'authentification des utilisateurs sera explicitee au chapitre suivant mais, 
pour l'instant, nous definirons le fichier /etc/passwd suivant : 

root: :0:0:Super User : /root: /bin/bash 

II suffit pour finir de declarer le nom du service dans /etc/sysconfig/network afin que 
le script /etc/rc.d/rc.inet2 le prenne en compte au prochain demarrage. 

I# Daemons 
DAEMONS="xinetd" 

Au demarrage suivant, nous obtenons la trace du lancement de xi netd. 

Starting daemons: xinetd 

Et nous pouvons done tester le service depuis un autre poste du reseau. 

1$ rdate 192.168.3.3 
[192.168.3.3] Mon Apr 8 19:27:27 2002 

En resume, une fois que le demon xi netd est installe et fonctionnel, l'ajout d'un service 
se resume a deux actions : 

• la mise en place du fichier de configuration sur /etc/xi netd . d, 

• la copie du programme demon declare dans ce fichier sur /sbi n. 



Connexion PPP 

On s'est pour l'instant attache, dans ce chapitre, a la configuration du reseau dans le cas 
d'une connexion a un reseau local via un adaptateur Ethernet. Dans certaines situations 
pourtant, meme isole de tout reseau local, un systeme embarque devra effectuer une con- 
nexion temporaire a un reseau distant (comme Internet), et ce en utilisant une simple 
ligne telephonique. Le protocole de connexion utilise est en general PPP (Point to Point 
Protocol). Les distributions Linux recentes fournissent des outils graphiques de configu- 
ration d'une connexion PPP, ce qui ne convient pas a une solution embarquee. 

Dans cette section, nous allons done decrire les composants qu'il faut installer et la con- 
figuration qui doit etre mise en place afin d'ajouter une couche client PPP a notre cible. 
La mise en place de PPP necessite quelques conditions au niveau du systeme. 

La validation du support PPP 

Celle-ci s'effectue au niveau du noyau Linux, dans le menu Network device support des 
options de configuration du noyau comme indique ci-apres : 
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Network device support | 


vy|v m| v n 


PLIP (parallel port) support 


Help | 


v y 


♦ m 


v " 


PPP (point-to-point protocol) support 


Help 


v y 


V " 


v " 


PPP multilink support (EXPERIMENTAL) 


Help 


v y 


V " 


v " 


PPP filtering 


Help 


v y 


♦ m 


v " 


PPP support for async serial ports 


Help 


v y 


♦ m 


v " 


PPP support for sync tty ports 


Help 


v y 


♦ m 


v " 


PPP Deflate compression 


Help 


v y 


♦ m 


v " 


PPP BSD- Compress compression 


Help 



Figure 6-1 

Validation du support PPP. 



Si vous utilisez une liaison asynchrone, ce qui est le cas le plus frequent pour un modem 
connecte sur un port serie, il est indispensable de valider l'option PPP support for async 
serial port. 

/-'installation du programme pppd 

Ce programme gere le protocole PPP au niveau de l'espace utilisateur de Linux. Nous 
l'utiliserons ici en mode client (il se connecte sur un serveur PPP distant) mais c'est le 
meme programme qui permettra de construire un serveur PPP avec un systeme Linux. La 
version Red Hat 7.2 du programme pppd utilise quelques bibliotheques supplementaires 
que nous devrons installer sur la cible dans /lib. 

# ldd /usr/sbin/pppd 

libpam.so.O => /I ib/1 ibpam.so.O (0x4001c000) 
libdl.so.2 => /lib/libdl.so.2 (0x40024000) 
libutil.so.l => /lib/libutil.so.l (0x40028000) 
libcrypt.so.l => /l ib/1 ibcrypt.so.l (0x4002b000) 
libc.so.6 => /lib/libc.so.6 (0x40059000) 
/lib/ld-linux.so.2 => /I ib/ld-1 inux.so.2 (0x40000000) 

Le programme lui-meme sera installe sur le repertoire /sbi n. 

L installation du programme chat 

Ce programme permet de dialoguer avec le modem et d'etablir la connexion telephoni- 
que avec le serveur distant. Ce programme utilise une procedure « j 'envoi e/j' attends » 
{expect/send), ce qui permettra de l'utiliser pour de nombreuses applications de scripts 
Linux. Le programme sera installe dans le repertoire /sbin. 

La creation du point d' entree /dev/ppp 

Le point d' entree doit etre cree par la commande : 

mknod /dev/ppp c 108 
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La mise en place du repertoire /etc/ppp 

Ce repertoire contient les fichiers de configuration des programmes precedents. Pour les 
fichiers de configuration, le package PPP installe les fichiers suivants : 

I/etc/ppp/options 
/etc/ppp/chap- secrets 
/etc/ppp/pap-secrets 

Le fichier options contient les options de pppd pour la connexion PPP par defaut. Les 
fichiers chap-secrets et pap-secrets contiennent respectivement les identificateurs et 
mots de passe pour l'utilisation des protocoles CHAP (Challenge Handshake Authentication 
Protocol) et PAP (Password Authentication Protocol) aupres du serveur d'acces PPP. Voici 
un exemple de contenu du fichier pap-secrets : 



# Secrets for authentication using PAP 

# cl ient server secret 
pficheux * mon_mot_de_passe 



IP addresses 



Ce qui indique que, pour tous les serveurs PPP utilises, le mot de passe PAP de l'utilisa- 
teur pficheux sera mon_mot_de_passe. En realite, le mot de passe sera crypte a la maniere 
des mots de passes Unix du fichier /etc/passwd (voir man crypt). II est egalement 
important que ce fichier ne soit lisible que par le super-utilisateur. 

I# Is -1 /etc/ppp/pap-secrets 
-rw 1 root root 282 fev 11 15:24 /etc/ppp/pap-secrets 

L' aspect du fichier chap-secret est identique. 

Le systeme pourra se connecter a differents serveurs PPP ; la liste des serveurs sera dis- 
ponible sur /etc/ppp/peers, a raison d'un fichier de configuration par serveur. 

§ cat /etc/ppp/peers/free 

ttySO 115200 crtscts usepeerdns noipdefault defaultroute 

connect '/sbin/chat -t 60 -v -f /etc/ppp/chat-f ree' 

noauth 

lock 

idle 120 

Le fichier indique la ligne utilisee par pppd pour se connecter au serveur distant. La con- 
figuration courante indique que le client recupere la configuration IP aupres du serveur 
(noi pdef aul t et usepeerdns) et met en place le routage par defaut sur la connexion PPP 
vers le serveur. 

On note egalement qu'il utilise la commande chat a laquelle on passe en parametre le 
script chat-free montre ci-apres : 



ABORT 


'NO CARRIER" 


ABORT 


'NO DIALTONE" 


ABORT 


'ERROR" 


ABORT 


'NO ANSWER" 


ABORT 


■BUSY" 


\d 


\dat" 


OK "at 


S.d2&clml" 
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I OK "atdt0860922000" 
CONNECT "" 

Ce script definit un dialogue de type « j'envoie/j' attends » (expect/send) entre le systeme 
et le modem. Les lignes ABORT indiquent des conditions d'erreur qui aboutissent 
a l'interruption de l'appel. En cas de reception finale de la chaine CONNECT, la con- 
nexion modem est consideree comme etablie et le programme pppd tente d'etablir le pro- 
tocol PPP. 

On peut tester la connexion PPP en utilisant la commande pppd comme suit : 

# pppd call free name pficheux 

En cas d'etablissement de la connexion PPP, le fichier /var/run/pppO . pi d sera cree et Ton 
pourra visualiser la nouvelle configuration reseau au moyen des commandes i f conf i g et 
route. 

# ifconfig 
lo Lien encap:Boucle locale 

inet adr:127. 0.0.1 Masque:255. 0.0.0 

UP L00PBACK RUNNING MTU : 16436 Metric:l 

RX packets:28 errors:0 dropped:0 overruns:0 frame:0 

TX packets:28 errors:0 dropped:0 overruns:0 carrier:0 

col 1 i si ons : lg file transmission^ 

RX bytes:1854 (1.8 Kb) TX bytes:1854 (1.8 Kb) 

pppO Lien encap: Protocol e Point-a-Point 

inet adr:62. 147.84.85 P-t-P: 192. 168.254.254 Masque: 255 . 255 . 255 . 255 

UP P0INT0P0INT RUNNING NOARP MULTICAST MTU:1500 Metric:l 

RX packets:4 errors:0 dropped:0 overruns:0 frame:0 

TX packets:5 errors:0 dropped:0 overruns:0 carrier:0 

col 1 i si ons : lg file transmission: 3 

RX bytes:64 (64.0 b) TX bytes:97 (97.0 b) 

# route 

Table de routage IP du noyau 

Destination Passerelle Genmask Indie Metric Ref Use Iface 

192.168.254.254 * 255.255.255.255 UH pppO 

127.0.0.0 * 255.0.0.0 U lo 

default 192.168.254.254 0.0.0.0 UG pppO 

Nous pouvons noter que la regie de routage par defaut est positionnee sur l'interface pppO 
correspondant a la connexion PPP. 

Pour couper la connexion, il suffira de tuer le processus pppd par : 

kill ~cat /var/run/pppO.pid" 

II est possible de visualiser la trace de la connexion et de l'etablissement du protocole si 
Ton installe le programme syslogd qui est le plus souvent utilise dans les applications 
systeme. Pour cela, il suffit de copier les deux composants, puis de lancer le demon. 

Icp /sbin/syslogd /mnt/emb/sbin 
cp /etc/syslog.conf /mnt/emb/etc 
/sbin/syslogd 
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Le demon peut bien entendu etre lance systematiquement a partir du script de demarrage 
/etc/rc.d/rc.S. Lorsque le demon est actif, on peut visualiser ce type de trace dans le 
fichier /var/log/messages : 

atdt0860922000 A M A M 
CONNECT 

-- got it 
send ( A M) 

Serial connection established. 
Using interface pppO 
Connect: pppO <--> /dev/ttySl 
BSD Compression module registered 
Deflate Compression module registered 
local IP address 62.147.84.85 
remote IP address 192.168.254.254 
primary DNS address 213.228.0.168 

Au moment de l'etablissement de la connexion PPP, pppd execute automatiquement le 
script shell /etc/ppp/ip-up qui peut etre adapte par l'utilisateur, ce qui permet d'asso- 
cier l'etablissement de la connexion au lancement d'une application. De meme, la cou- 
pure de la connexion s'accompagnera de l'execution du script /etc/ppp/ip-down. 
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En resume 



La mise en place d'une connexion reseau est un point tres important de la configura- 
tion d'un systeme Linux embarque. Nous utilisons pour cela les commandes systeme 
ifconfig et route. 

L utilisation de la cible en tant que client de nouveaux services reseau necessite la mise 
en place des 1 ibnss associees, et ce arm de satisfaire a 1' architecture de la glibc2. 

Une fois que le super-demon xinetd est installe, la mise en place de nouveaux services 
serveur est relativement aisee. 

Un systeme Linux embarque peut egalement etre connecte a un serveur PPP distant, et ce 
en ajoutant un minimum de composants au systeme. 



7 

Optimisation et mise 
au point du systeme 



Le chapitre precedent nous a permis de configurer le reseau de notre systeme Linux 
embarque et nous disposons d'ores et deja d'une version tres fonctionnelle. Le present 
chapitre va s'attacher a quelques points particuliers comme la configuration du clavier 
local, la mise en place d'un systeme d'authentification, la gestion de memoire flash ou la 
comparaison des types de systemes de fichier. 

Configuration du clavier 

Le clavier de la console Linux est configure par defaut en QWERTY (clavier anglais/ 
americain). Si vous devez faire des manipulations sur la console, il est interessant de dis- 
poser d'une configuration de clavier AZERTY. Le systeme de configuration comprend 
d'une part le programme 1 o ad keys, permettant le charge ment de la disposition du clavier 
(carte ou map), et d' autre part la carte elle-meme, contenue dans un fichier .kmap ou 
.kmap.gz (compresse avec gzip). 

Les fichiers kmap se trouvent dans le repertoire /l i b/kbd/keymaps. Dans les distributions 
classiques, ce repertoire contient un grand nombre de fichiers correspondant aux diffe- 
rents types de clavier selon les architectures materielles. Dans notre cas, nous ne copie- 
rons que le fichier correspondant a un clavier francais/latinl, ainsi que les differents 
fichiers annexes. Par ailleurs, nous copierons egalement le programme loadkeys, ainsi 
que le decompresseur gunzip. 

Imkdir -p /mnt/emb/1 ib/kbd/keymaps/i386/azerty 
cd /I ib/kbd/keymaps 
cp i386/azerty/f r-latinl. kmap.gz i386/azerty 
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cp -a -r i386/include i 386 

cp -a -r include . 

cp /bin/loadkeys /mnt/emb/bin 

cp /bin/gzip /mnt/emb/bin 

cp -a /bin/gunzip /mnt/emb/bin 

On peut maintenant modifier le fichier /etc/sysconf i g/general de la cible afin de defi- 
nir le type de clavier. 

I# General configuration 
KEYTABLE=fr 
KEYMAP=i386/azerty/fr-latinl 

Puis on peut ajouter la ligne suivante au fichier /etc/rc . d/rc . S de la cible, juste avant le 
lancement de l'interpreteur de commande : 



# Clavier 

/bin/loadkeys /I ib/kbd/keymaps/${KEYMAP} .kmap 



Au demarrage du systeme, on obtient alors : 

Loading /l ib/kbd/keymaps/i386/azerty/f r-latinl. kmap.gz 

Mise en place d'un systeme d'authentification 

Un systeme Linux est par defaut multi-utilisateur et dispose done d'un systeme d'authen- 
tification permettant aux utilisateurs references de se connecter. Cette authentification est 
le plus souvent basee sur la saisie d'un nom d'utilisateur ou login, suivie de l'entree d'un 
mot de passe ou password. Dans la version actuelle de notre cible, il n'y a pas d'authen- 
tification et le demarrage du systeme se termine par le lancement direct d'un interpreteur 
de commande en mode super-utilisateur. Cette configuration n'a qu'un but pedagogique 
et un systeme reel aura tres souvent besoin d'une fonction d'authentification. Celle-ci ne 
sera pas forcement utilisee sur une console locale car il faut pour cela que le systeme 
puisse disposer d'un ecran et d'un clavier. L' authentification sera egalement utile pour 
une connexion via un terminal serie ou bien a travers le reseau via une connexion Telnet, 
SSH ou FTP. 

Les premieres versions d'Unix utilisaient une authentification a travers une liste locale 
d'utilisateurs definie dans le fichier /etc/passwd. Les versions derivees de System V R4 
(SVR4) utilisent en plus le fichier /etc/shadow qui stocke les mots de passe cryptes asso- 
cies aux utilisateurs definis dans /etc/passwd. Les distributions Linux utilisent egale- 
ment une telle configuration. Dans une configuration complexe connectee a un reseau 
local, 1' authentification peut se faire a partir d'une base identique a la base locale, mais 
centralisee sur un serveur utilisant le protocole NIS (Network Information Service) deve- 
loppe par SUN Microsystems. 

En ce qui concerne le fonctionnement global de 1' authentification, Linux utilise egalement 
le principe d'Unix en respectant le schema suivant : 
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• Le programme getty affiche le message d'invite sur une console. Par defaut, ce mes- 
sage correspond a login. 

• Lorsque getty detecte une entree de caractere sur la console, il la saisit et la passe au 
programme login. 

• Le programme 1 ogi n se charge de demander le mot de passe a l'utilisateur en affichant 
par defaut la chaine Password. 

• En cas de saisie correcte du mot de passe, l'interpreteur de commande associe a 
l'utilisateur, et defini dans /etc/passwd, est execute. 

• En cas de saisie incorrecte, un message Login incorrect est affiche et le processus 
recommence. 

Le lancement du programme getty (appele agetty sous Linux) est declare dans le fichier 
/etc/inittab. 

|cl:1235:respawn:/sbin/agetty 38400 ttyl linux 
c2:1235:respawn:/sbin/agetty 38400 tty2 linux 

ttyl et tty2 correspondent a deux consoles « virtuelles », sur un meme ecran. On passe 
d'une console a 1' autre en utilisant les combinaisons de touches Ctrl-Afl-Fl et Ctrl-Alt- 
F2. Pour ajouter une nouvelle console virtuelle, il suffit d'ajouter une ligne au fichier /etc/ 
i ni ttab puis de redemarrer le systeme ou bien de taper i ni t q pour forcer le processus 
i ni t a relire son fichier de configuration. 

Le systeme d'authentification decrit ici avait dans sa version initiale une assez forte limi- 
tation car la mise en place d'une nouvelle politique d'authentification necessitait la modi- 
fication des outils associes comme login et passwd. Le probleme a ete resolu de maniere 
elegante en utilisant un systeme appele PAM (Pluggable Authentication Module) qui per- 
met de modifier le comportement de l'authentification en ajoutant simplement des biblio- 
theques dynamiques appelees « modules PAM ». Grace a PAM, il est possible d'ajouter 
une methode quelconque d'authentification en ajoutant au systeme une bibliotheque 
dynamique et un fichier de configuration. De nombreux modules existent deja pour 
s'authentifier aupres d'annuaires de type LDAP ou equivalent. 

De ce fait, les programmes comme login utilisent, outre celles qui sont habituelles, quel- 
ques autres bibliotheques, partagees. 

# ldd /bin/login 

libcrypt.so.l => /l ib/1 ibcrypt.so.l (0x4002d000) 
libpam.so.O => /I ib/1 ibpam.so.O (0x4005a000) 
libdl.so.2 => /lib/libdl.so.2 (0x40062000) 
1 ibpam_misc.so.0 => /l ib/1 ibpam_misc.so.O (0x40066000) 
libc.so.6 => /lib/i686/libc.so.6 (0x40069000) 
/lib/ld-linux.so.2 => /I ib/ld-1 inux.so.2 (0x40000000) 

De meme, il est necessaire d' installer sur le systeme un certain nombre de fichiers de 
configuration et bibliotheques partagees situees sur les repertoires /etc/pam.d et /lib/ 
security. 
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II est bien entendu possible de dupliquer ce comportement sur notre cible embarquee 
mais, dans un eternel souci de reduction de l'empreinte memoire, nous allons considerer 
que le systeme PAM n'est pas utile dans notre cas. Pour ce faire, il sera bien entendu 
necessaire de generer de nouvelles versions des programmes concernes ne faisant pas 
reference au systeme PAM. Nous devons pour cela installer les archives RPM sources de 
la distribution Red Hat 7.2, ou bien travailler directement sur les sources des program- 
mes. Une rapide recherche par rpm nous indique les noms de paquetages RPM associes 
au programme login. 

Iii rpm -qf /bin/login 
util-linux-2.11f-9 

Apres recuperation du paquetage source associe, nous l'installons sur notre systeme de 
developpement. 

rpm -ivh util -1 inux-2.llf-9.src. rpm 

Le paquetage en question est maintenant installe dans l'arborescence RPM du systeme, 
soit /usr/src/redhat. L' archive des sources et les « patches » a appliquer avant compi- 
lation sur Red Hat 7.2 sont disponibles sur le sous-repertoire SOURCES. L'arborescence 
des sources, non « patchee » pour l'instant, est disponible sur le sous-repertoire BUILD. 
Le fichier de specification RPM est disponible sur le sous-repertoire SPECS. Pour appli- 
quer les patches, il faut deja utiliser la commande : 

rpm -bp /usr/src/redhat/SPECS/util -1 inux.spec 

qui va generer une arborescence compatible avec Red Hat 7.2 sur le repertoire BUILD. II 
faut maintenant modifier les options de compilation du paquetage afin de supprimer le 
support PAM (HAVE_PAM). On peut egalement modifier le support des mots de passes 
masques {shadow password), ce qui permettra de limiter la liste des utilisateurs et mots 
de passe au fichier /etc/passwd. 

cd /usr/src/redhat/BUILD/util-linux-2.11f 

En editant le fichier MCONFIG, on peut modifier les options de compilation du support 
PAM. 

§ If HAVE_PAM is set to "yes", then login, chfn, chsh, and newgrp 

# will use PAM for authentication. Additionally, passwd will not be 

# installed as it is not PAM aware. 
HAVE_PAM=no 

# If HAVE_SHADOW is set to "yes", then login, chfn, chsh, newgrp, passwd, 

# and vipw will not be built or installed from the login-utils 

# subdirectory. 
HAVE_SHADOW=no 

Le repertoire login-utils contient les sources des programmes login, agetty et pas- 
swd ; il suffit done de compiler puis de copier les programmes au bon endroit : 



cd login-utils 



make agetty login passwd 
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Icp agetty /mnt/smb/sbin 
cp login passwd /mnt/emb/bin 

Au niveau du fichier /etc/inittab, et en plus de l'ajout de l'appel a agetty, il faut indi- 
quer au systeme de demarrer en mode multi-utilisateur (multi-user) et non plus en mono- 
utilisateur (single-user). Pour cela, on modifie le debut du fichier. 

# Default runlevel . 
id:3:initdefault: 

# System initialization (runs when system boots), 
si :S:sysinit : /etc/ red/ re. S 

# Script to run when going multi user, 
re : 123456: wait: /etc/ red/ re. M 

On ajoute un nouveau script rc.M qui pourra contenir des actions a lancer au passage en 
multi-utilisateur. Pour l'instant, le script contient seulement : 

#!/bin/sh 

# Script to run in multi-user mode 
echo "Multi-user mode." 

Apres redemarrage du systeme, on obtient a la fin : 

IINIT: Entering runlevel: 3 
Multi-user mode, 
local host. localdomain login: 



Remarque 

Dans le cas de I'utilisation de BusyBox, le systeme d'authentification est integre et peut etre mis en place en 
configurant I'entree « Login/Password Management Utilities » de la configuration BusyBox accessible par make 
menuconf ig. 



Configuration des disques flash 

Nous avons jusqu'a present utilise des disques durs ou disques flash munis d'une inter- 
face standard IDE. Ce choix est tres avantageux dans la majorite des cas car il ne neces- 
site pas de configuration particuliere du noyau Linux pour le pilotage de ces 
peripheriques. L' interface IDE entraine cependant un surcout au niveau du prix du mate- 
riel et il est parfois judicieux d'utiliser des memoires flash ne recourant pas a TIDE. Dans 
cette section, nous allons decrire la configuration du noyau pour le pilotage de disque 
flash M-Systems de type DOC2000 (ou Disk On Chip). La principale raison en est sim- 
plement la large diffusion de ce produit dans le monde des applications embarquees ; 
nombreux sont en effet les constructeurs de cartes mere industrielles qui fournissent un 
emplacement destine a ce type de composant. La capacite du composant va de 16 a 
568 Mo. Nous decrirons aussi brievement la configuration du pilote MTD pour les 
memoires flash de type CFI (Common Flash Interface). 
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La configuration du noyau pour la DOC2000 peut s'effectuer de deux manieres : 

• en utilisant le pilote fourni par M-Systems sous forme d'un « patch » du noyau, 

• en utilisant le driver MTD du noyau 2.4. 

Attention 

Le pilote MTD fonctionne avec les flash DOC2000 et Millenium mais ne fonctionne pas avec les flash Millenium 
Plus. Pour ces dernieres, il est imperatif d'utiliser le pilote fourni par M-Systems. 

Utilisation du pilote M-Systems 

Le pilote est disponible en telechargement sur le site de M-Systems a l'adresse http:// 
www.m-sys.com. Les composants sont repartis sur deux paquetages : 

• un paquetage contenant des utilitaires MS-DOS destines au formatage bas niveau de la 
flash ainsi que le BIOS driver M-Systems (tffs_dostools_5041.zip qui contient en 
particulier DFORMAT et DINFO) ; 

• un paquetage contenant le patch du noyau (pour les versions 2.0, 2.2 et 2.4), la docu- 
mentation d' installation ainsi que quelques utilitaires comme une version adaptee de 
LILO (doc-linux-5.0.0.tgz). 

Les utilitaires DOS necessitent l'installation d'un systeme d' exploitation compatible. Si 
Ton ne dispose pas de licence MS-DOS, on peut utiliser le clone DR-DOS/OPEN-DOS 
disponible en telechargement aupres de la societe Caldera sur l'URL http://www.drdos.net. 
Cette adresse permet de telecharger les images des trois disquettes d' installation. Les dis- 
ques flash de type DOC 2000 sont fournis deja formates avec une partition de type DOS 
deja creee. Pour formater le disque flash, il suffit d'utiliser la commande DFORMAT fournie 
dans l'archive des utilitaires DOS M-Systems. 

DFORMAT /WIN:D000 /S : D0C504. EXB 

Le fichier EXB correspond au firmware installe sur le disque flash. Une description com- 
plete des utilitaires DOS est disponible dans le document fourni avec l'archive tffs_ 
dostool s_5041 .zip. 

L' extraction de la deuxieme archive cree le repertoire doc-linux-5.0.0 qui contient le 
fichier README . install decrivant en detail l'installation du pilote sous Linux. Pour appli- 
quer le patch aux sources du noyau, il suffit de faire : 

Icd doc-1 inux-5.0.0/drivers 
./patch_l inux linux-2_4-patch driver-patch 
. /mknod_f 1 

Si le repertoire /usr/src/linux n'existe pas (ce qui est souvent le cas sur un systeme 
equipe d'un noyau 2.4), il faudra passer le repertoire des sources du noyau a modifier en 
troisieme parametre du script patch_l inux. La derniere ligne permet de creer les points 
d' entrees correspondant au pilote de la flash dans le repertoire /dev, soit : 
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§ Is -1 /dev/msys 
total 

brw i root root 10 o, o avr 14 21 

brw i root root 10 o, l avr 14 21 

brw i root root 10 o, 2 avr 14 21 

brw i root root 10 o, 3 avr 14 21 

brw i root root 10 o, 4 avr 14 21 

brw i root root 10 o, 64 avr 14 21 



47 fla 

47 flal 

47 fla2 

47 fla3 

47 fla4 

47 fib 



Lorsque le patch est applique, il suffit de valider le support M-Systems DOC device sup- 
port dans le menu Block devices de la configuration du noyau Linux. Si le disque flash est 
utilise comme peripherique de demarrage, vous pouvez dans un premier temps valider le 
support dans la partie statique du noyau (cocher y et non m). Sachez cependant que la dif- 
fusion d'un tel noyau n'est pas conforme a la licence du noyau Linux (la GPL) car le 
noyau statique genere est constitue de code GPL auquel est ajoute du code non-GPL 
(venant de M-Sy stems). Pour etre conforme a la GPL, vous devrez utiliser le support par 
modules, ce qui oblige a creer un disque memoire de demarrage ou initrd. L utilisation de 
la fonction initrd sera decrite au chapitre suivant. 

Lorsque le noyau est recompile puis installe comme decrit au chapitre 4, on peut d'ores 
et deja redemarrer le systeme et verifier la detection du disque flash dans les messages de 
demarrage, ou apres coup en utilisant la commande dmesg. 

Flash disk driver for DiskOnChip2000 

Copyright (C) 1998,2001 M-Systems Flash Disk Pioneers Ltd. 

DOC device(s) found: 2 

Fat Filter Enabled 

fl_geninit: registered device at major: 100 

Le disque est des maintenant accessible comme un disque classique en utilisant le device 
/dev/msys/f 1 a (pour le premier disque flash detecte). Le disque contient par defaut une 
partition MS-DOS qu'il faudra certainement remplacer par une partition Linux en recourant 
a l'utilitaire f di sk decrit au chapitre 5. 

# fdisk /dev/msys/f la 

Command (m for help) : p 

Disk /dev/msys/fl a: 16 heads, 4 sectors, 1001 cylinders 

Units = cylindres of 64 * 512 bytes 

Device Boot Start End Blocks Id System 

/dev/msys/fl al * 1 1001 32030 83 Linux 

Command (m for help): 

A partir de la, on peut creer n'importe quel type de partition (ext2, ext3, etc.) sur le 
device /dev/msys/fl al. La partition peut ensuite etre montee comme suit : 

mount -t ext3 /dev/msys/fl al /mnt/flash 

On peut egalement demarrer a partir du disque flash en utilisant la version speciale de 
LILO fournie sur l'archive M-Systems, soit sous forme de paquetages RPM, soit sous 
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§ cd doc-1 


inux-5.0.0/li 


lo/ 






# Is -1 












total 484 












-rw-rw-rw- 


1 


root 


root 


668 aou 
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-rw-r--r-- 


1 


root 


root 


34236 Jul 


30 


-rw-r--r-- 


1 


root 


root 


35369 Jul 


30 


-rw-r--r-- 


1 


root 


root 


190516 jui 


30 


-rw-r--r-- 
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root 


root 


32223 jui 


30 


-rw-r--r-- 


1 


root 


root 


183621 jui 


30 



forme d' archives au format tar . gz. Cette version speciale est necessaire car elle prend en 
compte la geometrie speciale du disque flash M-Systems, ce qui n'est pas le cas dans la 
version standard de LILO. 



2001 README. lilo 

2001 doc-1 ilo-0. 21-19.i 386. rhat52.rpm 

2001 doc-1 ilo-0. 21-19.i 386. rhat62.rpm 

2001 doc-lilo-0. 21-19. src.rpm 

2001 li1o-bin.21.tar.gz 

2001 lilo-src.21.tar.gz 

Avec l'installation d'un paquetage RPM binaire, on dispose du programme /sbin/doc- 
1 i 1 o et du secteur de boot special doc.b qui remplace le fichier standard boot.b utilise 
par LILO, comme decrit au chapitre 4. 

I# rpm -ql doc-1 i 1 o 
/boot/doc. b 
/sbin/doc-1 ilo 

Un fichier lilo. conf adapte au disque flash sera done du style : 

boot=/dev/msys/fla 

install=/boot/doc.b 

map=/boot/map 

read-only 

vga = normal 

§ End LILO global section 

image = /boot/bzImage-2.4.18_msys 

root = /dev/msys/flal 

label = linux 

Dans certains cas, il sera parfois necessaire de forcer le numero du disque (parametre 
bi os) par les lignes suivantes dans les parametres globaux : 

|disk=/dev/msys/fla 
bios=0x80 

Si la partition du disque est montee sur /mnt/f 1 ash et done le fichier lilo. conf present 
sur /mnt/f lash/etc, on installera LILO sur le secteur de demarrage du disque flash en 
utilisant la commande : 

/sbin/doc-1 ilo -r /mnt/flash -v 

Apres deconnexion des autres peripheriques de boot plus prioritaires et redemarrage du 
systeme, on devrait demarrer sur le disque flash. II est bien entendu necessaire de modi- 
fier prealablement les fichiers de configuration qui dependent du nom du peripherique 
contenant la partition principale (root filesystem), en particulier le fichier /etc/fstab 
present sur le disque flash. 
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Attention 

II est egalement indispensable de creer les entrees speciales /dev/msys sur le repertoire /mnt/flash/dev avant de 
demarrer le systeme sur le disque flash. 

Certaines versions de LILO sont incompatibles avec le BIOS M Systems installe par DFORMAT. II est alors 
conseille de mettre a jour LILO avec une version plus recente. Les sources de LILO sont disponibles a I'adresse 
ftp://sunsite.unc.edu/pub/Linux/system/boot/lilo. La description du probleme et des solutions se trouve 
dans le fichier README. install contenu dans I'archive doc-lilo-5.0.0.tgz. 



Utilisation du pilote MTD 

Le projet MTD (Memory Technology Device) est mene par David Woodhouse (dwm2 
@infradead.org) et la page d'accueil est disponible sur http://www.linux-mtd.infradead.org. 
Ce pilote a l'avantage d'etre totalement Open Source et de supporter un grand nombre de 
disques flash, dont les produits M-Systems, a 1' exception du modele Millenium Plus. Le 
but du projet est de mettre en place une interface simple entre le pilote materiel de la flash 
et les couches superieures du noyau Linux. Ce projet est egalement couple au developpe- 
ment du systeme de fichier JFFS2 (Journalling Flash File System version 2). MTD est 
integre a 1' arborescence des noyaux 2.4 et 2.6. 

Le seul defaut du projet MTD est un manque relatif de documentation concernant la con- 
figuration et l'utilisation des composants. Un fichier, mtd-jffs-HOWTO.txt, reprend 
cependant les procedures d' installation et de configuration. II est disponible depuis la 
page d'accueil du projet. 

Les dernieres versions contenant les pilotes et divers utilitaires sont disponibles depuis le 
serveur CVS du projet ou bien sous forme d'une copie journaliere au format tar.gz 
(daily snapshot) depuis la page d'accueil. Le projet est en perpetuelle evolution et il est 
done conseille de telecharger la derniere version aupres du serveur CVS plutot que d'uti- 
liser celle fournie dans le noyau Linux 2.4 ou 2.6. II faut cependant noter que seule la ver- 
sion 2.6 est maintenue a ce jour. Pour ce faire, il faut copier l'arbre CVS en local au 
moyen des commandes : 

Icd /usr/src 
cvs -d :pserver:anoncvs@cvs . i nf radead.org:/home/cvs login 

Apres saisie du mot de passe anonevs, il faut faire : 

cvs -d :pserver:anoncvs@cvs . i nf radead.org:/home/cvs co mtd 

ce qui a pour effet de creer un repertoire /usr/sre/mtd. On doit ensuite se positionner 
dans le repertoire patches afin de modifier les sources du noyau courant. 

cd /usr/sre/mtd/patches 

sh patchin.sh /usr/src/1 inux-2.4 

La configuration du noyau pour l'utilisation de MTD est decrite dans le fichier mtd-jffs- 
HOWTO.txt. Si nous devons utiliser le disque flash comme peripherique de demarrage, il 
sera plus simple de valider le support MTD dans la partie statique du noyau. La figure ci- 
apres indique la configuration a effectuer dans le menu principal du pilote MTD. 
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v y 


v m 


♦ n 


FTL (Flash Translation Layer) support 


Help 


♦ y 


v m 


v " 


NFTL (NAND Flash Translation Layer) support 


Help 


♦ y 


V " 


v " 


Write support for NFTL (BETA) 


Help 




RAM/ROM/Flash chip drivers 




Mapping drivers for chip access 




Self-contained MTD device drivers 




NAND Flash Device Drivers 






Main Menu 


Next Prev 









Figure 7-1 

Configuration principale de MTD. 

En cliquant sur 1' option Self-contained MTD device drivers, ce qui correspond entre 
autres aux disques flash M-Systems ; on obtient l'ecran de configuration suivant : 





Disk- On- Chip Device Drivers 


v y 


v m 


♦ n 


M- Systems Disk- On- Chip 1000 


Help 


♦ y 


v m 


v " 


M-Systems Disk-On-Chip Z000 and Millennium 


Help 


v y 


v m 


♦ n 


M-Systems Disk-On-Chip Millennium -only alternative driver (see help) 


Help 


v y 


V " 


♦ n 


Advanced detection options for DiskOnChip 


Help 



Figure 7-2 

Validation du support DOC 2000. 



La validation du support du systeme de fichiers JFFS2 est quant a elle effectuee dans 
le menu File systems du menu principal de configuration du noyau, comme indique sur la 
figure ci-apres : 
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File systems | 


v y 


v m 


♦ n 


Joumalling Flash File System (JFFS) support 


Help 


^ 





JFFS debugging verbosity (0 = quiet, 3 = noisy) 


Help 


v y 


V " 


v n 


JFFS stats available in /proc filesystem 


Help 


♦ y 


v m 


v n 


Joumalling Flash File System vZ (JFFSZ) support 


Help 


F~ 






JFFSZ debugging verbosity (0 = quiet, Z = noisy) 


Help 



Figure 7-3 

Validation du support JFFS2. 



Comme pour le pilote M-Systems, il est necessaire de creer les points a" entree corres- 
pondants dans le repertoire /dev. On utilise pour cela le script MAKEDEV fourni dans le 
repertoire uti 1 des sources du projet MTD. 

Apres compilation et installation du nouveau noyau, le redemarrage du systeme doit pro- 
voquer l'affichage d'un message, tel que celui-ci : 

IDiskOnChip 2000 found at address OxDOOOO 
Flash chip found: Manufacturer ID: 98, Chip ID: 73 (Toshiba TH58V128DC) 
2 flash chips found. Total DiskOnChip size: 32 Mi B 

Le pilote MTD permet egalement d'obtenir des informations via le systeme de fichiers 
virtuel /proc. 

I# cat /proc/mtd 
dev: size erasesize name 
mtdO: 02000000 00004000 "DiskOnChip 2000" 

Comme pour le pilote M-Systems, on peut manipuler le disque flash avec les utilitaires 
classiques. 

# fdisk /dev/nftla 

Command (m for help) : p 

Disk /dev/nftla: 16 heads, 4 sectors, 1001 cylinders 

Units - cylindres of 64 * 512 bytes 



Device Boot 


Start 


End 


Blocks 


Id 


System 


ev/nftlal * 


1 


1001 


32030 


83 


Linux 



Command (m for help): 

Une fois la partition creee, on peut alors creer un systeme de fichier ext2 ou ext3 en uti- 
lisant la commande mke2fs sur le device /dev/nftlal, qui est un device de type bloc. 
La creation d'un systeme JFFS2 utilise le device de type caractere /dev/mtdO et sera 
decrite dans la prochaine section concernant les systemes de fichiers. Le montage de la 
partition ne presente pas de difficulte. 

§ mount -t ext3 /dev/nftlal /mnt/flash 
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Le boot sur le disque flash necessite la encore une version modifiee de LILO. Une 
archive du LILO modifie est disponible sur le repertoire patches des sources du projet 
MTD. 

§ tar tzvf patches/1 ilo-mtd. tar. gz 

-rw-r--r-- dvir/dvir 4540 2000-03-18 16:43:00 boot.b-mtd 

-rwxr-xr-x dvir/dvir 51500 2000-03-19 17:44:00 1 ilo-mtd 

-rw-r— -r-- dvir/dvir 2361 2000-03-04 19:51:00 1 ilo21-mtd-patch 

Un fichier 1 i 1 o . conf adapte est tres similaire au fichier precedent. 

boot=/dev/nftla 

install=/boot /boot.b-mtd 

map=/boot/map 

read-only 

vga = normal 

§ End LILO global section 

image = /boot/bzImage-2.4.18_mtd 

root = /dev/nftlal 

label = linux 

On installe le secteur de demarrage avec la commande : 

# /sbin/1 ilo-mtd -r /mnt/flash -v 

Patched LILO for M-Systems' DiskOnChip 2000 

LILO version 21, Copyright 1992-1998 Werner Almesberger 

Reading boot sector from /dev/nftla 

Warning: /dev/nftla is not on the first disk 

Merging with /boot/boot. b-mtd 

Boot image: /boot/bzImage-2.4.18_mtd 

Added linux * 

Backup copy of boot sector in /boot/boot. 5D00 

Writing boot sector. 



Attention 

II est egalement indispensable de dupliquer sur /mnt/flash/dev les noeuds crees par le script makedev avant de 
demarrer le systeme sur le disque flash. 



Les memoires flash CFI (Common Flash Interface) 

Le pilote MTD precedemment decrit permet egalement de piloter les memoires de type 
CFI. Le standard CFI a ete developpe par Intel et permet d'utiliser des memoires de 
marques differentes avec la meme couche logicielle. Une introduction au standard CFI 
est disponible en ligne chez Intel a l'adresse http://developer.intel.com/design/flcomp/cfi_ 
bg.htm. 

L utilisation necessite le support generique MTD comme dans le cas des DOC 2000. En 
plus de cela, il faut selectionner le type de flash en cliquant sur RAM/ROM/Flash chip 
driver dans la page principale de configuration MTD. On obtient l'ecran suivant : 
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RAM/ROM/Flash chip drivers | j | J 


RAM/ROM/Flash chip drivers | 


♦ y 


v m 


v " 


Common Flash Interface (CFI) support 


Help 


A 
/ 


♦ y 


V " 


v " 


CFI Virtual erase regions (EXPERIMENTAL) 


Help 


♦ y || v - 


v " 


CFI Advanced configuration options 


Help 


NO Flash cmd/query data swapping 


Help 


♦ y || v - 


v " 


Specific CFI Flash geometry selection 


Help 


v y 


V " 


♦ n 


Support 8 -bit buswidth 


Help 


v y 


V " 


♦ n 


Support 1 G-bit buswidth 


Help 


♦ y 


V " 


v " 


Support 32-bit buswidth 


Help 


v y 


V " 


♦ n 


Support 1 -chip flash interleave 


Help 


v y 


V " 


♦ n 


Support Z-chip flash interleave 


Help 


♦ y 


V " 


v " 


Support 4-chip flash interleave 


Help 


♦ y 


v m 


v " 


CFI support for Intel/Sharp Basic/Extended Commands 


Help 


♦ y 


v m 


v " 


CFI support for AMD/Fujitsu Standard Commands 


Help 


♦ y 


v m 


v " 


AMD compatible flash chip support (non-CFI) 


Help 


♦ y 


v m 


v " 


pre-CFI Sharp chip support 


Help 


♦ y 


v m 


v " 


Support for RAM chips in bus mapping 


Help 


♦ y 


v m 


v " 


Support for ROM chips in bus mapping 


Help 


v y 
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♦ n 


JEDEC device support 


Help 






OK Next Prev 









Figure 7-4 

Selection du type de flash. 

sur lequel on devra valider le type de flash et eventuellement la geometrie. Si la flash est 
visible dans l'espace memoire du processeur, on devra selectionner les caracteristiques 
de l'adressage en cliquant sur Mapping drivers for chip access dans la page principale de 
configuration MTD. 



Mapping drivers for chip access j 




♦ y 


v m 


v n 


CFI Flash device in physical memory map 


0x8000000 


Physical start address of flash mapping 


0x4000000 


Physical length of flash mapping 


F~ 






Bus width in octets 



Figure 7-5 

Adressage de la flash. 
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Utilisation dune cle USB 

La cle USB est un peripherique de plus en plus populaire et dont le cout n'a cesse de 
baisser ces dernieres annees. On peut aujourd'hui trouver des cles USB de bonne capa- 
city pour quelques dizaines d' euros au point de constituer un support marketing de choix. 
Certaines societes commercialisent des cles USB deja equipees du systeme Linux (voir 
http://www.flonix.com) mais il est relativement aise de mettre en place une distribution 
reduite sur un tel peripherique. Une telle distribution peut etre tres interessante a des fins 
de demonstration, de tests ou d'outils de maintenance car on pourra alors avoir sa propre 
distribution dans la poche ! 

Une cle USB est vue sous Linux comme un disque SCSI. La plupart des distributions 
actuelles integrent le support des cles USB en natif (dans le noyau livre) et 1' insertion de 
la cle provoque l'affichage du message suivant dans les traces du systeme. 

Sep 21 12:13:26 localhost kernel: hub.c: new USB device 00:07.2-1, assigned address 2 

Sep 21 12:13:26 localhost kernel: usb.c: USB device 2 (vend/prod 0xea0/0x6803) 

*»is not claimed by any active driver. 

Sep 21 12:13:27 localhost kernel: SCSI subsystem driver Revision: 1.00 

Sep 21 12:13:27 localhost kernel: Initializing USB Mass Storage driver... 

Sep 21 12:13:27 localhost kernel: usb.c: registered new driver usb-storage 

Sep 21 12:13:27 localhost kernel: scsiO : SCSI emulation for USB Mass Storage devices 

Sep 21 12:13:27 localhost kernel: Vendor: OTi Model: Flash Disk Rev: 1.11 

Sep 21 12:13:27 localhost kernel: Type: Direct-Access ANSI SCSI revision: 02 

Sep 21 12:13:27 localhost kernel: USB Mass Storage support registered. 

La cle est utilisable a travers le fichier special /dev/sda et Ton peut bien entendu la par- 
titionner, formater, monter, etc. La cle suivante contient deux partitions de 16 Mo, l'une 
au format VFAT pour les transferts Windows, 1' autre au format EXT3 contenant une 
mini-distribution Linux. L' existence de cette deuxieme partition Linux ne trouble en rien 
l'utilisation de la cle sous Windows. 

Le demarrage sur la cle pose quelques petits problemes : 

• Le BIOS du PC doit permettre le demarrage sur support disque USB. C'est le cas de la 
majorite des PC specialises pour les applications embarquees (EDEN, LEX, etc.) mais 
ce n'est pas le cas des PC grand public. 

• La detection de la cle USB lors du demarrage du noyau Linux est asynchrone par rap- 
port au montage du systeme de fichiers principal (ou root filesystem). De ce fait, un 
noyau Linux standard ne pourra pas utiliser comme root filesystem une partition d'une 
cle USB. Cependant la modification a apporter au noyau pour permettre cette utilisa- 
tion est minime et se limite a un patch de quelques lignes applique au fichier ini t/do_ 
mounts . c. II existe plusieurs patches disponibles, celui-ci est accessible depuis le FAQ 
du site http://www.linux-usb.org. Ce probleme est egalement present pour le noyau 2.6 et 
le meme type de patch sera applicable. 

Le principe de la modification est simple : on ajoute une attente de quelques secondes 
(maximum 5 essais) pour laisser le temps a la cle USB d'etre detectee. Ce n'est pas tres 
elegant mais c'est simple et cela fonctionne. Les quelques lignes de code a ajouter a la fin 



Optimisation et mise au point du systeme 

Chapitre 7 

de la fonction mount_root( ) sont presentees ci-dessous. II existe d'autres patches dispo- 
nibles et accessibles depuis la FAQ du site http://www.Linux-usb.org. 

/* 

* Patch for USB boot 
*/ 

{ 
/* beqin iordi **************************** */ 

static DECLARE_WAIT_QUEUE_HEAD ( jordi_queue) ; 

printk ("\n\n\n \n"); 

printk (" WAITING FOR A WHILE (1000) \n"); 

printk (" TO DETECT THE USB DISK \n"); 

sleep_on_timeout (&jordi_queue, 1000); 

printk (" \n\n\n"); 

/* end iordi **************************** */ 
) 
/* End of patch */ 

mount_block_root("/dev/root" , rootjnountflags) ; 
} 

Au niveau de la configuration du noyau, il faudra valider les differentes options (SCSI et 
USB) en statique pour permettre la detection de la cle USB en tant que disque de demar- 
rage. Les options a valider sont simples : 

• Valider SCSI support et SCSI disk support dans le menu SCSI support. 

• Valider Support for USB, le type de controleur USB (OHCI ou UHCI) ainsi que USB 
mass storage support dans le menu USB support. 

Au niveau du fichier /etc/fstab, on fera reference au fichier special /dev/sdal pour 
monter le systeme de fichiers principal. 

/dev/sdal / ext3 defaults 1 1 

Concernant 1' installation de LILO, le principe est le meme que pour les disques durs IDE 
(puisque c'est egalement un peripherique en mode bloc) sauf qu'il faut utiliser /dev/sda 
au lieude /dev/hda : 

boot=/dev/sda 

map=/boot/map 

instal l=/boot/boot.b 

prompt 

timeout=50 

defaul t=l inux 

image=/boot/bzImage-2.4.27-usb 
1 abel=l inux 
read-only 
root=/dev/sdal 
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Les d if fe rents types de systemes de fichiers 

Nous avons installe sur notre cible le systeme de fichier ext3, derive de ext2 et tres fre- 
quemment utilise sur Linux. Pour un systeme embarque, nous rappelons que la contrainte 
d'un systeme de fichier « journalise », done resistant aux arrets imprevus, est tres impor- 
tante. 

Ext2/ext3 

Le systeme de fichier ext3 est 1' extension journalisee du systeme de fichier ext2 qui est le 
type le plus repandu sur les systemes Linux. Historiquement, ext2 a ete developpe au 
MASI, ex-laboratoire de l'universite Jussieu de Paris, par Remy Card, pour une version 
universitaire d'un systeme Unix like appele MASIX. Les deux systemes sont compatibles 
et Ton peut meme utiliser une partition ext3 sur un noyau supportant uniquement ext2, 
mis a part le journal, qui ne sera pas pris en compte. Nous avons utilise ext3 au chapitre 5 
car il est d'un emploi tres aise sur n'importe quel peripherique en mode bloc. II est inte- 
gre a l'arborescence des sources du noyau Linux 2.4 et maintenu par la societe Red Hat. 

ReiserFS 

Contrairement a ext3, ReiserFS fut concu des le depart comme un systeme de fichier 
journalise. De conception plus recente, il est tres efficace dans le cas de partitions de 
grandes tailles gerant nombre de petits fichiers. II a ete initialement developpe par 
Hans Reiser a l'universite de Stanford a Palo Alto. Hans Reiser a depuis cree une societe 
commerciale autour de ReiserFS (NAMESYS). Bien qu'integre dans l'arborescence 
des sources de noyaux Linux 2.4 et 2.6, les dernieres versions sont disponibles sur 
http://www.namesys.com. L'utilisation sur la Red Hat 7.2 necessite 1' installation du paque- 
tage rei serf s-uti 1 s. On peut creer un tel systeme de fichier sur un peripherique de type 
bloc en utilisant la commande mkrei serfs. 

II est cependant peu adapte a un environnement embarque car limite a une taille mini- 
male de partition de 32 Mo. 



JFFS2 



JFFS2 (Journaling Flash File System, version 2) est intimement lie au projet MTD decrit 
dans ce chapitre. II a pour origine le systeme JFFS initialement developpe par la societe 
suedoise AXIS (http://developer.axis.com/software/jffs) sur le noyau 2.0. JFFS et JFFS2 
sont maintenant integres dans l'arborescence des noyaux 2.4 et 2.6 et les dernieres 
versions sont disponibles sur le serveur CVS du projet MTD decrit precedemment. Outre 
des ameliorations structurelles concernant la gestion des blocs errones (bad blocks) et la 
recuperation d'espace (garbage collector), une caracteristique interessante de JFFS2 par 
rapport a JFFS est la fonction de compression des donnees en temps reel. La validation 
du support de JFFS et/ou JFFS2 se fait au niveau du menu File systems de la configuration 
du noyau. 
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Pour creer un systeme de fichier JFFS2, il faut utiliser le programme mkfs. jffs2 dispo- 
nible sur la distribution MTD ou sur le serveur CVS dans le repertoire uti 1 . La proce- 
dure est decrite dans le document mtd-jffs-HOWTO.txt. En resume, outre la detection de 
la memoire flash decrite aux sections precedentes, la creation du systeme de fichier se 
resume aux actions suivantes : 

I# mkfs.jffs2 -d /home/jffs2_stuff -o /tmp/jffs2.img 
# cp /tmp/jffs2.img /dev/mtdO 

La premiere ligne correspond a la creation d'une image du systeme de fichier dans un 
fichier unique a partir d'un repertoire contenant 1' arborescence a copier. La deuxieme 
ligne copie simplement ce fichier sur le device correspondant a la memoire flash utilisee. 
Si la memoire flash n' a jamais ete initialisee, notez qu'il est necessaire de le faire avec la 
commande erase disponible sur le meme repertoire d'utilitaires. 

# erase /dev/mtdO 

Pour monter le systeme de fichier, il suffit de faire : 

# mount -t jffs2 /dev/mtdblockO /mnt/flash 

Notez que Ton utilise le device mtdbl ockO car la commande mount necessite un periphe- 
rique en mode bloc. 



CRAMFS 



CRAMFS (Compressed ROM File System) est un systeme de fichier en lecture seule uti- 
lisant l'algorifhme de compression de la z1ib (identique a gzip). La taille maximale de 
chaque fichier est limitee a 16 Mo et la taille totale du systeme de fichier est limitee a 
256 Mo. Pour utiliser CRAMFS, il faut deja valider le support dans la configuration du 
noyau dans la rubrique Filesystems. CRAMFS utilise une image generee avec l'utilitaire 
mkcramfs qui permet de creer un fichier image a partir d'un repertoire. Les sources de 
l'utilitaire sont disponibles a l'adresse http://cvs.bofh.asn.au/cramfs. 

# mkcramfs MicroW microw.img 
Directory data: 14092 bytes 
Everything: 4252 kilobytes 
Super block: 76 bytes 
CRC: 8647fdf8 

Le fichier image pourra ensuite etre monte en utilisant la fonction de loopback du noyau 
Linux. II faut pour cela avoir valide en module ou en statique 1' option dans le menu Block 
devices/Loopback device support de la configuration du noyau. Cette fonction permet de 
monter un fichier image (par exemple, un fichier image ISO d'un CD-Rom) exactement 
comme si Ton montait le support reel. Dans le cas du fichier CRAMFS, on fera : 

mount -t cramfs -o loop microw.img /mnt/cramfs 

si /mnt/cramfs est un point de montage valide. 
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Utilisation des disques memoire 

Le noyau Linux offre la possibility de travailler sur des disques memoire ou ramdisks. 
L' utilisation d'un disque memoire a de nombreux avantages, dont la rapidite d'acces aux 
donnees mais aussi le faible cout de la RAM par comparaison avec d'autres supports 
physiques comme la memoire flash. Pour utiliser des disques memoire, il faut deja vali- 
der le support dans le noyau Linux avec le menu Block devices comme decrit dans la 
figure ci-apres : 



Mapping drivers for chip access | 




♦ y 


v m 


v n 


CFI Flash device in physical memory map 


0x8000000 


Physical start address of flash mapping 


0x4000000 


Physical length of flash mapping 


F~ 






Bus width in octets 



Figure 7-6 

Support des disques memoire. 



Le principe du noyau Linux est d'allouer automatiquement un certain nombre de disques 
de taille fixe, cette taille etant par defaut definie dans le noyau. La valeur par defaut est de 
4096 octets. On peut modifier cette valeur dans la configuration presentee ci-apres, mais 
egalement passer la nouvelle valeur lors du demarrage du systeme a travers le chargeur 
LILO: 

| LILO: linux ramdisk_size=8192 

Comme decrit precedemment, cette configuration pourra etre ajoutee au fichier /etc/ 
1 i 1 o . conf grace a une directive append : 

append="ramdisk_size=8182" 

Chaque disque memoire est vu a travers un pilote de type bloc /dev/ramX, X variant de 
a 20. Ce device est utilisable comme n'importe quel peripherique de stockage en mode 
bloc. On pourra par exemple creer un systeme de fichier d'une taille de 2 Mo en faisant : 

I# dd if=/dev/zero of=/dev/ram2 bs=lk count=2048 
# mke2fs -vmO /dev/ram2 2048 

Le systeme peut ensuite etre monte et utilise comme n'importe quel systeme de fichier. 

# mount -t ext2 /dev/ram2 /mnt/tmp 

# df /mnt/tmp 

Filesystem lk-blocks Used Available Use% Mounted on 

/dev/ram2 2011 13 1998 11 /mnt/tmp 

On peut done imaginer de remplir ce systeme de fichier avec les composants d'un root 
file system minimal comme nous l'avons fait au chapitre 5. Une fois le systeme cree, il est 
possible de compresser le resultat en un fichier unique. Dans 1' exemple qui suit, nous 
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considerons que le systeme de fichier en question est suffisamment petit pour tenir au 
maximum sur une disquette apres compression avec gzip. 

dd if=/dev/ram2 bs=lk count=2048 | gzip -v9 > /tmp/ram_image.gz 

Nous pouvons ensuite creer une disquette de demarrage (bootable) a partir d'un noyau 
sur lequel nous aurons valide le support des disques memoire. 

dd if=bzlmage of=/dev/fdO bs=lk 

II faut ensuite copier 1' image compressee du systeme de fichier sur la meme disquette (et 
sur une autre, si l'espace restant n'est pas suffisant). Si Ton estime que le noyau occupe 
au maximum 400 Ko et que l'espace doit etre suffisant sur la meme disquette, on peut 
copier l'image apres le noyau en faisant : 

dd if=/tmp/ram_image.gz of=/dev/fdO bs=lk seek=400 

On indique ensuite au noyau que le root file system sera lu sur une disquette, et ce au 
moyen de la commande rdev. 

rdev /dev/fdO /dev/fdO 

II reste a indiquer au noyau la localisation du systeme de fichier a l'aide de la meme com- 
mande. La manipulation du disque memoire avec rdev est effectuee grace a 1' option -ra 
laquelle on passe le nom du device contenant l'image du disque memoire (ici, /dev/fdO 
pour la disquette) suivie de la valeur d'un masque decimal de parametrage. Le tableau 
suivant donne la signification des valeurs. 

Tableau 7-1 . Parametres de rdev -r 



Bits 


Parametre 


Description 


0a10 


ramdisk_start 


Position dans le support 


11 a13 


Non utilise 


Fixe a 


14 


load_ramdisk 


Chargement du ramdisk 


15 


prompt_ramdisk 


Arret avant chargement 



Les noms des parametres indiques correspondent a ceux que LILO devrait passer au 
noyau pour obtenir le meme resultat que la commande rdev. 

Les bits a 10 indiquent la position de l'image compressee du disque memoire par rap- 
port au debut du support. Dans notre cas, la valeur est 400. Si l'image est sur une autre 
disquette, la valeur est 0. 

Le bit 14 indique au noyau qu'un disque memoire doit etre charge et le bit 15 indique au 
noyau de demander confirmation a l'utilisateur avant de charger le disque memoire arm 
de permettre le changement de support si necessaire. Si nous validons ces 2 bits nous 
obtenons 2 A 15 + 2 A 14 + 400 = 49 552. Si l'arret n'est pas necessaire la valeur sera 
2 A 14 + 400 = 16 784. On en deduit la commande. 

rdev -r /dev/fdO 16784 
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Dans le cas d'une image copiee sur une deuxieme disquette la valeur sera 2 A 15 + 
2 A 14 + = 49 152, soit la commande : 

rdev -r /dev/fdO 49152 

ce qui correspond a une ligne de commande LILO du type : 

ramdisk_start=0 load_ramdisk=l prompt_ramdisk=l 

La technique du disque me moire est frequemment utilisee pour la fonction initrd qui 
permet a un noyau de monter un systeme de fichier principal (root file system) initial a 
partir d'un disque memoire. Le but est de definir un demarrage en deux phases, une pre- 
miere permettant d'acceder a tous les peripheriques (par exemple, un disque SCSI de 
demarrage) et une seconde phase utilisant un noyau dont la partie statique est reduite au 
minimum, done ne contenant pas les pilotes SCSI. Le nom du fichier correspondant a 
l'image memoire a charger est defini dans le fichier 1 i 1 o . conf . 

image=/boot/vml inuz-2.4.7-10 
label=l inux 

initrd=/boot/initrd-2.4.7-10.img 
read-only 
root=/dev/hdal 

Le fichier . img est compresse avec gzip, et l'option -9. On peut visualiser son contenu en 
utilisant la fonction loopback decrite precedemment : 

# file initrd-2.4.7-10. img 

i ni trd-2 .4 . 7-10 . i mg : gzip compressed data, deflated, last modified: Fri Apr 26 
** 10:46:07 2002, max compression, os: Unix 
it gunzip -c initrd-2.4.7-10. img > /tmp/i 

# Is -1 /tmp/i 

-rw-r— r-- 1 root root 3072000 avr 29 17:27 /tmp/i 

§ mount -t ext2 -o loop /tmp/i /mnt/tmp 

# Is /mnt/tmp/ 
bin dev etc lib linuxrc loopfs proc sbin sysroot 

La racine du systeme de fichier contient un script 1 inuxrc qui est execute apres le char- 
gement du disque memoire initial et qui permet normalement de basculer sur le systeme 
definitif. Le disque memoire est ensuite monte sur un point de montage /initrd. Quand 
le script 1 inuxrc n'existe pas, le systeme ne sort jamais du disque memoire et Ton peut 
done envisager d'utiliser cette fonction pour un systeme embarque minimal. 



Un exemple d'utilisation de CRAMFS et disque memoire 

Si Ton observe la structure d'un systeme Linux, on s'apercoit qu'une grande majorite du 
systeme de fichiers peut etre configuree en lecture seule. Mises a part quelques excep- 
tions que nous decrirons plus loin, les parties necessitant l'acces en lecture-ecriture sont 
les suivantes : 



le repertoire /var contenant des donnees de fonctionnement souvent volatiles ; 
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• le repertoire /tmp encore plus volatile ! 

• les repertoires de configuration (exemple : definition d'adresse IP, etc.) ; 

• les repertoires d'utilisateurs ou applicatifs (exemple : stockage de donnees enregis- 
trees par le systeme). Ces derniers pourront etre places sur un veritable disque dur et il 
est egalement possible de monter la partition a la demande afin de limiter les risques. 

Outre la derniere categorie que nous ne traiterons pas ici, il est done relativement simple 
de mettre en place 1' architecture suivante : 

• La majorite du systeme est sur une partition en lecture seule de type CRAMFS. 

• Le repertoire /var (point de montage) est sur un disque memoire. 

• Le repertoire /tmp est un lien symbolique sur /var/tmp. 

• Le repertoire de configuration utilisera un format classique (EXT2, EXT3, JFFS2 ou 
meme Minix). La partition est de tres faible taille. On peut meme imaginer de stacker 
cette configuration sur une partition non formatee (au format TAR directement ecrit 
sur le fichier special de la partition) ce qui limite les risques de problemes de systeme 
de fichiers dus a la coupure d' alimentation. Dans un systeme reel on pourra meme sauver 
les fichiers de configuration sur une partition creee sur une memoire sauvegardee de 
type SRAM. 

A titre d'exemple concret nous supposerons que nous utilisons un DiskOnChip de 8 Mo. 
Cette configuration correspond au cas reel d'un routeur Wi-Fi construit sur la base d'un PC 
de type PC Light base sur un processeur VIA C3. Le principe est d'utiliser trois partitions 
sur la memoire flash : 

• Une premiere partition /dev/nftlal correspondant a /boot et contenant le noyau et 
les composants de LILO. II n'est pas necessaire que cette partition soit montee lors du 
fonctionnement du systeme mais seulement lors de la mise a jour eventuelle du noyau 
depuis un environnement de developpement. De ce fait, cette partition sera formatee 
en EXT2. 

• Une deuxieme partition /dev/nftla2 contenant le systeme de fichiers. Elle sera for- 
matee en CRAMFS comme decrit plus loin. 

• Une troisieme partition /dev/nf tl a2 contenant les quelques fichiers de configuration. 
Elle est de tres petite taille et utilise en premiere approche un formatage EXT2. 

Le fichier /etc/f stab decrivant les montages sur le systeme cible aura Failure suivante : 



bash-2.05# cat 


/etc/fstab 










/dev/nftla2 


/ 


cramfs 


defaults 


1 


1 


/dev/nftla3 


/data 


ext2 


defaults 








none 


/dev/pts 


devpts 


mode=622 








none 


/proc 


proc 


noauto 








/dev/ramO 


/var 


ext2 


defaults 









On note que la partition /boot n'est pas montee mais que nous avons une partition /var 
montee sur un disque memoire /dev/ramO. Pour la deuxieme partition (systeme de 
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fichiers principal), nous utiliserons le systeme de fichiers CRAMFS. Pour utiliser CRAMFS, 
il faut disposer du programme mkcramf s. La version livree avec certaines distributions 
ne fonctionne pas forcement tres bien et il vaut mieux recuperer la version officielle 
disponible sur le site du projet, soit http://sourceforge.net/projects/cramfs. 

Pour construire une partition CRAMFS sur un support physique on devra tout d'abord 
creer 1' image du repertoire au format CRAMFS. 

# mkcramf s my_root my_root.img 
Directory data: 14092 bytes 
Everything: 4252 kilobytes 
Super block: 76 bytes 
CRC: 8647fdf8 

On pourra ensuite copier l'image sur la partition par un simple dd ou un cp : 

| # dd < my_root.img > /dev/nftla2 

Au niveau du noyau, il faudra bien entendu valider le support de CRAMFS en statique au 
niveau du menu File systems de la configuration du noyau. Puisque nous utilisons egale- 
ment un disque memoire, il faudra valider le support Ramdisk le menu Block devices. La 
taille par defaut de 4 Mo pour le disque memoire est suffisante pour notre application. 

Si nous faisons reference au chapitre 4, nous savons que le demarrage du systeme est 
divise en 5 etapes : 

• le demarrage du systeme par LILO (Linux LOader) ou un programme equivalent type 
GRUB ; 

• le chargement du noyau ; 

• le lancement par le noyau du processus i ni t (soit /sbi n/i ni t) ; 

• lecture du fichier /etc/inittab par le processus init. Ce fichier contenant le nom du 
fichier de demarrage comme decrit ci-dessous. 

I# System initialization (runs when system boots), 
si :S: sys init: /etc/ red/ rc.S 

• l'execution du script ci-dessus. 

Sachant que le repertoire /var est place dans un disque memoire, il est necessaire de 
construire l'arborescence de ce dernier a chaque demarrage du systeme. On aura done 
dans le fichier rc.S les lignes suivantes : 

# Create /var (EXT2 filesystem) 
/sbin/mke2fs -vmO /dev/ramO 4096 

# mount file systems in fstab (and create an entry for /) 

# Mount /proc first to avoid warning about /etc/mtab 
mount /proc 
/bin/mount -at nonfs 
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§ Populate /var 

mkdir -p /var/tmp /var/log /var/lock /var/run /var/spool /var/lib/dhcp /var/run/dhcpc 
mkdir -p /var/cron/tabs /var/www/html /var/spool /cron /var/spool/mail /var/ppp 
chmod a+rwx /var/tmp 



Outre la creation de /var, on notera le lien symbolique de /etc/mtib vers /proc/mounts. 
Ce lien est necessaire car /etc n'est pas accessible en ecriture. 



I 



I rwxrwxrwx 



1 root 



root 12 Jun 23 2003 mtab -> /proc/mounts 



De meme, on notera l'utilisation frequente des liens symboliques afin de permettre a des 
fichiers crees au demarrage d'apparaitre dans le systeme de fichiers en lecture simple 
(voir exemple de /etc/resolv.conf ci-dessous). Les fichiers variables sont systemati- 
quement places dans le repertoire /var/run : 



# Is -1 /etc/resolv.conf 
1 rwxrwxrwx 1 root root 



20 Sep 24 07:53 /etc/resolv.conf -> /var/run/resolv.conf 



Concernant les fichiers de configuration, ils sont places dans le repertoire /data associe a 
la troisieme partition : 



# Is -1 /dat 


i/sysconfig/ 










total 6 












-rw-r--r-- 


1 65534 


nobody 


41 Jun 


23 


2003 general 


-rw-r--r-- 


1 65534 


nobody 


349 Sep 


17 


21:14 network 


-rw-r--r-- 


1 root 


root 


174 Jun 


23 


2003 ppp 


-rw-r--r-- 


1 root 


root 


150 Sep 


6 


2003 pppoe 


-rw-r--r-- 


1 root 


root 


16 Jun 


23 


2003 syslogd.opts 


-rw-r--r-- 


1 root 


root 


150 Jun 


24 


2003 wireless 



Mise au point des programmes 
Utilisation de GDB 

La mise au point des programmes ou « debogage » est un mal necessaire connu de tous 
les developpeurs. Lorsqu'on travaille sur une station Linux, la tache est facilitee par l'uti- 
lisation du debogueur symbolique GDB (GNU DeBugger) qui permet d'executer le 
programme en pas a pas, de gerer des points d'arret, ou pire encore. 

Si le systeme cible utilise une version tres proche de celle du poste de developpement, 
nous essaierons la plupart du temps de regler les problemes directement sur la station de 
developpement en s'approchant au maximum de l'environnement de la cible. Dans le 
cas ou des problemes inherents a l'environnement cible subsistent, GDB offre la possi- 
bility d'effectuer un debogage a distance (remote debugging) a travers un lien RS-232 
ou une connexion reseau TCP/IP. Meme si ce n'est pas directement lie au sujet de 
l'ouvrage, nous allons brievement rappeler quelques concepts generaux concernant 
l'utilisation de GDB. 
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Si nous considerons le petit programme C qui suit : 

#inc1ude <stdio.h> 
#include <stdlib.h> 



void affiche (int v) 



printf ("valeur= %d\n", v); 



) 



main (int ac, char **av) 
{ 

int i ; 

for (i = ; i < 5 ; i++) 
affiche (i ) ; 
} 



Ce dernier pourra etre compile sous Linux avec la commande : 

$ gcc -g -o affiche affiche. c 

Puis execute par : 

$ ./affiche 
valeur= 
valeur= 1 
valeur= 2 
valeur= 3 
valeur= 4 

L' option -g indique au compilateur d'ajouter les informations de debogage utilisables par 
GDB. Si nous lancons la meme execution sous la commande gdb, nous obtenons : 

$ gdb affiche 

GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_0UT) 

Copyright 2001 Free Software Foundation, Inc. 

GDB is free software, covered by the GNU General Public License, and you are 

welcome to change it and/or distribute copies of it under certain conditions. 

Type "show copying" to see the conditions. 

There is absolutely no warranty for GDB. Type "show warranty" for details. 

This GDB was configured as "i386-redhat-l inux" . . . 

(gdb) 

Si nous posons un point d'arret sur la fonction af f i che( ), et que nous demarrons le pro- 
gramme, nous obtenons le resultat suivant : 

(gdb) b affiche 

Breakpoint 1 at 0x8048466: file affiche. c, line 6. 

(gdb) r 

Starting program: /home/pierre/tmp/affiche 

Breakpoint 1, affiche (v=0) at affiche. c:6 
6 printf ("valeur= &d\n", v); 
(gdb) c 
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Continuing. 
valeur= 

Breakpoint 1, affiche (v=l) at affiche.c:6 
6 printf ("valeur= %d\n", v); 

(gdb) c 
Continuing. 
valeur= 1 

Breakpoint 1, affiche (v=2) at affiche. c:6 
6 printf ("valeur= %d\n", v); 

(gdb) 

Ce type de manipulation tres classique ne presente aucune difficulte dans un environne- 
ment de station de developpement Linux. Supposons a present que Ton veut mettre au 
point un programme execute sur une machine cible nominee portable depuis un poste de 
developpement nomme duron. Nous partons du principe que les deux machines sont con- 
nectees au meme reseau local TCP/IP, mais elles pourraient egalement etre reliees par un 
simple cable serie RS-232. 

Pour mettre au point le programme, nous devons bien evidemment disposer du programme 
gdb sur le poste de developpement, mais egalement d'un programme « serveur » sur le 
poste cible. Ce programme est nomme gdbserver et fait partie de la distribution des sour- 
ces gdb. En revanche, il n'est en general pas distribue dans le paquetage RPM binaire car 
son utilisation est reservee a un usage tres particulier. Pour information, ce programme 
est livre en standard dans les distributions Linux embarquees specialisees, comme Lynux- 
Works BlueCat ou Lineo Embedix. Le couple gdb/gdbserver peut bien entendu etre uti- 
lise sur des architectures differentes si celles-ci sont supportees par gdb et gdbserver. 

Pour compiler gdbserver, nous pouvons partir du paquetage RPM source de gdb disponi- 
ble sur ftp://ftp.redhat.com/redhat/redhat-7.2-en/os/i386/SRPMS/gdb-5.0rh-15.src.rpm. Nous 
pouvons egalement partir des sources de gdb disponibles sur ftp://ftp.gnu.org/pub/gnu/gdb. 

Comme decrit dans ce chapitre, nous pouvons installer le paquetage source au moyen de : 

| rpm -ivh gdb-5.0rh-15.src.rpm 
puis appliquer les « patches » propres a la Red Hat 7.2 par la commande : 

| rpm -bp /usr/src/redhat/gdb.spec 

Nous devons ensuite nous positionner sur le repertoire des sources, puis generer le fichier 
Makefile. 



cd /usr/src/redhat/BUILD/gdb+dejagnu-20010813/gdb 
./configure 



puis compiler et installer le programme gdbserver. 



cd gdb/gdbserver 

make 

make install 
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Sur le poste de developpement duron, nous disposons du source du programme af f i che . c 
et de l'executable affiche compile avec l'option -g. 

[pierre@duron pierre]$ Is -1 

total 32 

-rwxr-xr-x 1 pierre pierre 24622 mai 2 08:19 affiche 

-rw-r--r-- 1 pierre pierre 194 mai 2 08:21 affiche. c 

Sur la machine cible, nous devons disposer d'une copie de l'executable affiche. Cote 
cible, nous devons tout d'abord lancer gdbserver sur le programme af f i che. 

I[pierre@portable tmp]$ gdbserver duron:2345 affiche 
Process affiche created; pid = 12810 

Nous choisissons d'utiliser un lien reseau entre les deux machines. Le premier parametre 
de gdbserver est le nom reseau (ou l'adresse IP) du poste de developpement associe au 
numero de port TCP a utiliser, ici 2345. 



Attention 

Nous rappelons que les ports inferieurs a 1 024 ne doivent pas etre utilises, car reserves au systeme. De meme, 
il faut prendre soin de choisir un port non utilise par une autre application utilisateur. 



Cote poste de developpement, il suffit de lancer gdb avec le nom du programme en para- 
metre. La selection de la cible a deboguer s'effectue grace a la commande target. 

$ gdb affiche 

GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_0UT) 

Copyright 2001 Free Software Foundation, Inc. 

GDB is free software, covered by the GNU General Public License, and you are 

welcome to change it and/or distribute copies of it under certain conditions. 

Type "show copying" to see the conditions. 

There is absolutely no warranty for GDB. Type "show warranty" for details. 

This GDB was configured as "i386-redhat-l inux" . . . 

(gdb) target remote portable:2345 

Remote debugging using portable:2345 

0x40001e60 in ?? () 

(gdb) 

Cote cible, la ligne suivante est affichee : 

Remote debugging using duron:2345 

A partir de la, on peut utiliser gdb de maniere classique en posant par exemple un point 
d'arret sur la fonction afficheO. 

(gdb) b affiche 

Breakpoint 1 at 0x8048466: file affiche. c, line 6. 

(gdb) c 

Continuing. 

Breakpoint 1, affiche (v=0) at affiche. c:6 
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warning: Source file is more recent than executable. 

6 printf ("valeur= %d\n", v); 
(gdb) n 

7 } 
(gdb) c 
Continuing. 

Breakpoint 1, affiche (v=l) at affiche.c:6 

6 printf ("valeur= %d\n", v); 
(gdb) n 

7 } 

Cote cible, on obtient l'affichage de l'execution du programme. 

|valeur= 
valeur= 1 

Si Ton inhibe le point d' arret et que Ton rinit l'execution du programme, l'execution se 
termine cote cible et gdbserver s'arrete. On obtient cote poste de developpement : 

(gdb) dis 1 
(gdb) c 
Continuing. 

Program exited with code 0224. 
(gdb) 

et cote cible : 

valeur= 2 
valeur= 3 
valeur= 4 

Child exited with retcode = 94 

Child exited with status 
GDBserver exiting 
[pierre@portable tmp]$ 

On pourra de la meme maniere utiliser une connexion par un cable serie RS-232 sur le 
port COM1 (/dev/ttySO) en lancant cote cible : 

gdbserver /dev/ttySO nom_programme 
et cote systeme de developpement : 

gdb nom_programme 
puis dans gdb : 

(gdb) target remote /dev/ttySO 

Si Ton veut utiliser une autre vitesse que 9600 bits/s, on devra preciser l'option --baud a 
gdb. 
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Utilisation de s trace 

La commande s trace permet de visualiser les appels systemes et les signaux utilises 
dans un programme. Le resultat de strace est assez verbeux comme en temoigne le test 
effectue sur notre petit programme affiche. La sortie de strace peut cependant etre 
parametree en utilisant 1' option -e. 

$ strace ./affiche 

execveC. /affiche", ["./affiche"], [/* 22 vars */]) = 

uname( {sys="Linux" , node="duron.localdomain" , ...}) = 

brk(O) = 0x804964c 

open("/etc/ld. so. preload", 0_RD0NLY) = -1 ENOENT (No such file or directory) 

open("/etc/ld. so. cache", 0_RD0NLY) = 3 

fstat64(3, {st_mode=S_IFREG|0644, st_size=38627, ...}) = 

old_mmap(NULL, 38627, PR0T_READ, MAP_PRIVATE, 3, 0) = 0x40017000 

close(3) = 

open("/lib/i686/libc.so.6", 0_RD0NLY) = 3 

read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 \306\1"..., 1024) = 1024 

fstat64(3, {st_mode=S_IFREG|0755, st_size=5772268, ...}) = 

old_mmap(NULL, 4096, PR0T_READ| PR0T_WRITE, MAP_PRI VATE | MAP_AN0NYM0US , -1, 0) = 

*• X40021000 

old_mmap(NULL, 1290088, PR0T_READ| PR0T_EXEC, MAP_PRIVATE, 3, 0) = 0x40022000 

mprotect( 0x40154000, 36712, PR0T_N0NE) = 

old_mmap(0x40154000, 20480, PR0T_READ| PR0T_WRITE. MAP_PRIVATE|MAP_FIXED, 3, 0x13 

* 1000) = 0x40154000 
old_mmap(0x40159000, 16232, PR0T_READ| PR0T_WRITE. MAP_PRI VATE | MAP_FIXED | MAP_AN0N 

* YMOUS, -1, 0) = 0x40159000 
close(3) = 
munmap(0x40017000, 38627) = 

fstat64(l, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 
mmap2(NULL, 4096, PR0T_READ| PR0T_WRITE. MAP_PRI VATE | MAP_AN0NYM0US , -1,0)= 0x40 
** 017000 
writed, "valeur= 0\n", 10valeur= 

10 

10valeur= 1 



writed, "valeur= l\n" 
) = 10 

writed, "valeur= 2\n" 
) = 10 

writed, "valeur= 3\n" 
) = 10 

writed, "valeur= 4\n" 
) = 10 

munmap(0x40017000, 4096) 
_exit(d073743148) 



10valeur= 2 
10valeur= 3 
10valeur= 4 



= 
= ? 



La commande strace peut etre tres utile dans le cas de la mise au point d'un pilote de 
peripherique. 
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Detection des problemes de memoire 

Le probleme de depassement de memoire allouee est la bete noire de tous les deve- 
loppeurs C/C++. En general, cela tient a ce qu'un programme utilise de la memoire qu'il 
n'a pas prealablement allouee. Le cas typique est le depassement de tableau, lorsqu'on 
alloue un certain nombre d'elements d'un tableau dynamique avec l'appel systeme 
mall oc( ) et que Ton utilise ensuite plus d'elements que le nombre prevu. 

Le probleme est d'autant plus epineux qu'il n'apparait pas forcement immediatement au 
cours de 1' execution du programme car il a trait a la memoire disponible, et done a la 
charge du systeme. Dans le cas d'un systeme embarque, les consequences peuvent etre 
dramatiques car le defaut peut apparaitre bien apres la phase de developpement. 

Le petit programme C presente ci-apres alloue par exemple 10 cellules d'un tableau de 
caracteres, mais en utilise 20. 

#include <stdio.h> 

//include <stdlib.h> 

main (int ac, char **av) 
{ 

register int i ; 

char *tab = calloc (1, 10); 

for (i = ; i < 20 ; i++) 
*(tab+i) = i ; 

for (i = ; i < 20 ; i++) 
printf ("tab[%d]= Jd\n". 1. *(tab+i)) : 
} 

Apres compilation et execution, le systeme n'y voit pourtant que du feu. 

$ gec -g -o buggy buggy. c 

$ ./buggy 

tab[0]= 

tab[l]= 1 

tab[2]= 2 

tab[3]= 3 

tab[18]= 18 
tab[19]= 19 

Pour detecter ce type de probleme, nous devons utiliser un allocateur de memoire special. 
Les distributions classiques fournissent le paquetage ElectricFence (la « barriere electri- 
fiee »), qui remplace l'allocateur standard par une version de debogage. Pour cela, il faut 
installer le paquetage associe. 



rpm -ivh ElectricFence-2.2.2-8.i386. rpm 
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II suffit ensuite de compiler le programme en utilisant la bibliotheque libefence. Une 
nouvelle execution du programme detecte bien un probleme de memoire et le programme 
est interrompu avec une erreur de segmentation (signal SIGSEGV). 

$ gcc -g -o buggy buggy. c -lefence 
$ ./buggy 

Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce Perens <bruce@perens .com> 
Segmentation fault 

Le systeme doit des lors generer un fichier core qui permet de localiser l'erreur. Si le 
fichier core n'est pas present, il faut verifier la configuration de la session grace a la com- 
mande ul imit -c. Si la valeur est 0, il faut la modifier en donnant la nouvelle valeur 
« unlimited ». Une nouvelle execution du programme generera cette fois-ci un fichier 
core (message core dumped). 

$ ul imit -c 



$ ul i mi t -c unlimited 

$ ul imit -c 

unlimited 

$ ./buggy 

Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce Perens <bruce@perens .com> 
Segmentation fault (core dumped) 

Le debogueur gdb permet ensuite de localiser l'erreur. 

$ gdb buggy core 

GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_0UT) 

Copyright 2001 Free Software Foundation, Inc. 

GDB is free software, covered by the GNU General Public License, and you are 

welcome to change it and/or distribute copies of it under certain conditions. 

Type "show copying" to see the conditions. 

There is absolutely no warranty for GDB. Type "show warranty" for details. 

This GDB was configured as "i386-redhat-l inux" . . . 

Core was generated by *. /buggy'. 

Program terminated with signal 11, Segmentation fault. 

Reading symbols from /usr/1 ib/1 ibefence.so.O. . .done. 

Loaded symbols for /usr/1 ib/1 ibefence.so.O 

Reading symbols from /I ib/i686/l ibc.so.6. . .done. 

Loaded symbols for /l i b/i 686/1 ibc.so.6 

Reading symbols from /l ib/i686/l ibpthread.so.O. . .done. 

warning: Unable to set global thread event mask: generic error 

[New Thread 1024 (LWP 1671)] 

Error while reading shared library symbols: 

Cannot enable thread event reporting for Thread 1024 (LWP 1671): generic error 

Reading symbols from /l ib/1 d - 1 inux. so. 2. . .done. 

Loaded symbols for /I ib/1 d - 1 inux. so. 2 

#0 0x080485b5 in main (ac=l, av=0xbffffb64) at buggy. c:ll 

11 *(tab+i) = i; 

(gdb) 
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On peut egalement executer le programme buggy directement dans gdb, ce qui conduit au 
meme resultat. 

$ gdb buggy 

GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_0UT) 

Copyright 2001 Free Software Foundation, Inc. 

GDB is free software, covered by the GNU General Public License, and you are 

welcome to change it and/or distribute copies of it under certain conditions. 

Type "show copying" to see the conditions. 

There is absolutely no warranty for GDB. Type "show warranty" for details. 

This GDB was configured as "i386-redhat-l inux" . . . 

(gdb) r 

Starting program: /home/pierre/buggy 

[New Thread 1024 (LwP 1675)] 

Electric Fence 2.2.0 Copyright CC) 1987-1999 Bruce Perens <bruce@perens.com> 

Program received signal SIGSEGV, Segmentation fault. 

[Switching to Thread 1024 (LWP 1675)] 

0x080485b5 in main (ac=l. av=0xbffffb54) at buggy. c:ll 

11 *(tab+i) = i; 

(gdb) 

La bibliotheque ef ence permet de detecter les debordements de memoires mais certains 
produits commerciaux, beaucoup plus complexes (et plus couteux), ont d'autres fonc- 
tionnalites interessantes comme la detection de fuites de memoire. Nous pouvons citer le 
produit Insure++ edite par Parasoft (http://www.parasoft.com). 



En resume 



Le present chapitre a decrit quelques fonctions et methodes tres utiles pour le developpe- 
ment d'un systeme Linux embarque. Concernant les disques et memoires flash, les pro- 
duits M-Systems sont tres repandus et peuvent etre utilises soit avec des pilotes fournis 
par le constructeur, soit via la couche MTD integree dans le noyau Linux 2.4. Le pilote 
M-Systems utilisant une bibliotheque non-GPL, le fait de redistribuer un noyau Linux 
contenant ce pilote en statique n'est pas conforme a la GPL. On pourra alors utiliser un 
disque memoire initial (initrd) contenant les modules M-Systems ou bien utiliser le 
pilote MTD. 

La couche MTD permet egalement de piloter d'autres types de memoires flash comme 
les produits compatibles CFI. 

Differents formats de systeme de fichiers incluant des fonctionnalites de journalisation 
et/ou de compression en temps reel sont utilisables dans un environnement Linux embarque. 
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Autres techniques 

de demarrage : Loadlin, 

LinuxBIOS, Red Boot 

Un autre systeme de demarrage : LOADLIN 

LOADLIN est un programme permettant de charger un noyau Linux depuis un systeme de 
type MS-DOS. Le principal interet, outre le fait de ne pas avoir a modifier le secteur de 
demarrage du systeme, en est de pouvoir charger Linux apres avoir initialise le materiel 
dans un environnement DOS. 

La syntaxe de chargement du noyau est la suivante : 

c:\loadlin\loadlin.exe c:\linux\vmlinuz root=/dev/hda3 ro 

qui signifie que l'image vml i nuz est chargee depuis DOS et utilise la partition /dev/hda3 
comme partition principale, montee initialement en lecture seule. 

LOADLIN est egalement utilise dans certains systemes embarques de petite taille initiale- 
ment destines a 1' environnement DOS. La carte d'evaluation DIL decrite au chapitre 3 
et diffusee par SSV (http://www.ssv-embedded.de) utilise ce principe, que nous allons 
decrire en tant qu' illustration fonctionnelle de LOADLIN et des disques memoire. Comme 
decrit au chapitre 3, le systeme est constitue d'un processeur AMD compatible 486, de 
8 Mo de RAM et 2 Mo de memoire flash. Le test presente ici est realise sur une carte 
d'evaluation permettant le dialogue via un port serie ou un lien Ethernet comme decrit 
dans la figure ci-apres : 
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Systeme embarque 




Lienseiie RS-232 



Systeme de 
deVeloppement 



in inn i urn 'linn \ ~ == \ \ 



d 



awe 



Lien ethernet 



^ 



Hote 



Figure 8-1 

Connexions DIL/NetPC. 



Le poste de developpement est equipe d'un emulateur de terminal comme mini com, fourni 
en standard sur les distributions Linux. Au demarrage du DIL/NetPC, on obtient V affichage 
suivant : 

ESB486 for DIL/NetPC DNP/1486-3V V.0.15 
Copyright 2000 SSV SOFTWARE SYSTEMS GmbH 

TESTING INTERVAL TIMER PASS 

TESTING INTERRUPT CONTROLLER PASS 

TESTING DMA CONTROLLER PASS 

TESTING SYSTEM MEMORY 640K PASS 

TESTING EXTENDED MEMORY 7168K PASS 

TESTING REAL TIME CLOCK PASS 

TESTING CMOS RAM CHECKSUM PASS 

FlashFx 4.02.204 (386 DOS) 

Copyright (c) 1993-1999, Datalight Inc. 

Datalight Patent US#5860082 

Starting ROM-DOS... 

HIMEM V7.10 (Revision 3.00.44) 
Copyright (c) 1989-2000 Datalight, Inc. 
Using PS2 A20 Control (ON) 
32 XMS handles available. 
Minimum HMA usage is OK. 

VDISK v6.22 (Revision 3.00.44) 
Copyright (c) 1989-2000 Datalight, Inc. 

Installed 4096KB XMS RAM disk as drive D: 
C:> 



La flash contient une version reduite d'un systeme compatible MS-DOS. 
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C:\>dir 

Volume in drive C is SSD 

Volume Serial Number is 133C-13F0 

Directory of C:\ 



COMMAND 


COM 


34 


685 05-02-2000 


12:30p 


AUTOEXEC 


BAT 




32 03-06-2000 


6:05p 


CONFIG 


SYS 




74 05-02-2000 


12:12p 


HIMEM 


SYS 


5 


833 05-02-2000 


12:29p 


RB 


COM 


3 


095 05-02-2000 


12:54p 


SB 


COM 


2 


997 05-02-2000 


12:54p 


VDISK 


SYS 


8 


092 05-02-2000 


12:29p 


LINUX 


<DIR> 
8 filets) 




01-01-1980 

54,808 bytes 

176,640 bytes 


12:00a 
free 



Le systeme fournit deux programmes RB.COM et SB.COM permettant respectivement de 
recevoir et d'envoyer des fichiers via le port serie en utilisant le protocole Y-MODEM. Le 
repertoire Linux contient une arborescence similaire a celle decrite a la section precedente. 



C:\>cd linux 
C:\LINUX>dir 

Volume in drive C is SSD 

Volume Serial Number is 133C-13F0 

Directory of C:\LINUX 







<DIR> 




01-01-1980 


12:00a 






<DIR> 




01-01-1980 


12:00a 


LOADLIN 


EXE 




10 


819 01-01-1980 


12:05a 


RIMAGE 


GZ 




996 


972 01-01-1980 


12:36a 


ZIMAGE 






418 


978 01-01-1980 


12:10a 


START 


BAT 






161 01-01-1980 


12:11a 




6 fi 


e(s) 




1,426,930 bytes 
176,640 bytes 


free 



Le fichier ZIMAGE constitue le noyau Linux qui utilise le fichier RIMAGE. GZ comme image 
compressee de disque memoire. Le script START . BAT permet de demarrer le noyau Linux 
grace a l'utilitaire LOADLIN. EXE. 

C:\LINUX>type start.bat 

@echo off 

ECHO Start Embedded Linux for DilNet ... 

loadlin zimage console=ttyS0, 115200 initrd=rimage.gz root=/dev/ram 

ECHO Embedded Linux stopped or failed! 

Vu que Linux est charge uniquement en memoire vive, toutes les modifications effectuees 
apres le demarrage sont perdues a V arret du systeme. Les modifications permanentes doivent 
etre sauvegardees dans le fichier RIMAGE. GZ Apres lancement de la commande START, on 
obtient l'ecran suivant : 
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Linux version 2.2.5 (root@mha) (gcc version egcs-2.91.66 19990314 (egcs-1.1.2 

*• release)) #11 Fri Jun 30 11:09:38 MEST 2000 

Console: colour *CGA 80x25 

Calibrating delay loop... 16.54 BogoMIPS 

Memory: 5740k/8192k available (748k kernel code, 412k reserved, 288k data, 28k init) 

Checking if this processor honours the WP bit even in supervisor mode... Ok. 

CPU: AMD 02/0a stepping 04 

Checking 'hit' instruction... OK. 

Posix conformance testing by UNIFIX 

Linux NET4.0 for Linux 2.2 

Based upon Swansea University Computer Society NET3.039 

NET4: Unix domain sockets 1.0 for Linux NET4.0. 

NET4: Linux TCP/IP 1.0 for NET4.0 

IP Protocols: ICMP, UDP, TCP 

Starting kswapd v 1.5 

Serial driver version 4.27 with no serial options enabled 

ttySOO at 0x03f8 (irq = 4) is a 16550A 

Keyboard timeout[2] 

Keyboard timeout[2] 

RAM disk driver initialized: 16 RAM disks of 20480K size 

loop: registered device at major 7 

RAMDISK: Compressed image found at block 

Uncompressing done. 

VFS: Mounted root (minix filesystem). 

Freeing unused kernel memory: 28k freed 

ethO: cs8900 rev J found at 0x300 media RJ-45, IRQ 5 02 80 ad 20 26 b6 ;-) 

ethO: using lOBase-T (RJ-45) 

SSV DNPX Linux - Version 0.04 
emblinux login: 

Un compte gast est disponible pour acceder au systeme. Ce dernier est egalement dispo- 
nible en acces Telnet et FTP. 

emblinux login: gast 
Password: 

# Is -1 

# pwd 
/home/gast 
# 

Nous allons maintenant effectuer une modification de l'image RIMAGE.GZ en y ajoutant 
un petit programme de test sur /home/gast. Pour cela, il faut deja recuperer le fichier 
RIMAGE.GZ sur le poste de developpement en utilisant la commande SB.COM sous DOS. 

C:\LINUX>..\SB RIMAGE.GZ 

SB.C0M Send Y-ModemG (Batch) Version 0.17 (c) SSV 2000 
Ready to send file(s) 'RIMAGE.GZ'. End with CTRL-C! 
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Cote poste de developpement, on utilise la fonction de reception X/Y/Z-MODEM de 
mini com qui est activee en saisissant Control-X R. Lorsque le fichier est sur le poste 
de developpement, il faut le decompresser puis le monter en utilisant le device loopback. 



# gunzip RIMAGE 


GZ 














# mount -t 


minix -o 1 


oop RIMAGE 


/mnt/loopO 










# Is -1 /mn 


t/loopO 














total 17 


















drwxr-xr-x 


2 


root 


root 


2144 


jun 


11 


2001 


bin 


drwxr-xr-x 


2 


root 


root 


64 


jun 


28 


2000 


boot 


drwxr-xr-x 


2 


root 


root 


1984 


jui 


4 


2000 


dev 


drwxr-xr-x 


14 


root 


root 


1376 


avr 


30 


09:13 


etc 


drwxr-xr-x 


3 


root 


root 


96 


jun 


7 


2000 


home 


drwxr-xr-x 


3 


root 


root 


416 


jui 


10 


2000 


lib 


drwxr-xr-x 


2 


root 


root 


64 


mar 


3 


1999 


mnt 


drwxr-xr-x 


2 


root 


root 


64 


fev 


9 


2000 


proc 


drwxrwx — 


2 


root 


root 


64 


jun 


15 


2000 


root 


drwxr-xr-x 


2 


root 


root 


864 


jui 


3 


2000 


sbin 


drwxrwxrwt 


2 


root 


root 


64 


jun 


15 


2000 


tmp 


drwxr-xr-x 


6 


root 


root 


192 


mai 


25 


2000 


usr 


drwxr-xr-x 


7 


root 


root 


288 


mar 


20 


1998 


var 



Notez que cette image utilise le systeme de fichier minix (premier systeme de fichier uti- 
lise par Linux) et non le systeme de fichier ext2. Cela ne change rien a la suite. 

On cree ensuite un programme minimal en C, que Ton compile en utilisant l'option -s 
afin de reduire la taille de l'executable. Le fichier hel 1 o est ensuite copie dans le repertoire 
/mnt/1 oopO/home/gast. 

# cat hel lo.c 
main () 
{ 

printf ("hello world\n"); 
) 

# cc -s -o hel lo hel lo.c 

# Is -1 hello 
-rwxr-xr-x 1 root root 3012 avr 30 10:03 hello 

# ./hello 
hello world 

# cp hello /mnt/loopO/home/gast 

On demonte ensuite le systeme et Ton compresse de nouveau le fichier RIMAGE. 

I# umount /mnt/1 oopO 
# gzip -9 RIMAGE 

II reste a transferer la nouvelle image compressee sur la cible en utilisant la commande 
RB . COM et la sequence Control-X S cote mi ni com. 

IC:\LINUX>..\RB 
RB.COM Receive Y-ModemG (Batch) Version 0.17 (c) SSV 2000 
Wait for Files. End with CTRL-C! 
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II reste a demarrer de nouveau Linux et a tester le programme he! 1 o. 

emblinux login: gast 
Password: 

# Is -1 
-rwxr-xr-x 1 root root 3012 Apr 30 2002 hello 

# ./hello 
hel lo world 

LinuxBIOS 

Le projet LinuxBIOS (http://www.linuxbios.org) vise a remplacer le BIOS par un noyau Linux 
modifie sur des systemes de type x86 et Alpha. Comme la majorite des systemes d'exploi- 
tation modernes, Linux n'utilise pas le BIOS et sa presence est plus une contrainte qu'un 
avantage. L'utilisation de LinuxBIOS a la place du BIOS traditionnel est avantageuse sur 
plusieurs points : 

• Au niveau des performances, car le temps de demarrage du BIOS est supprime et il ne 
reste que le temps de boot du noyau Linux. 

• Au niveau de la securite, car le BIOS est desormais un vrai noyau Linux avec un 
administrateur unique. 

• Au niveau de la maintenance, car celle-ci peut etre faite a distance. De meme, le systeme 
peut etre controle depuis une console serie ou un acces reseau. 

LinuxBIOS est d'ores et deja disponible pour plusieurs chipsets Intel, compatibles et 
Alpha. Une page d'information maintient la liste des chipsets supportes par LinuxBIOS 
sur http://www.acl.lanl.gov/linuxbios/status. 

Plusieurs produits commerciaux utilisent egalement LinuxBIOS (voir http://www.acl 
.lanlgov/linuxbios/products). La societe CWLINUX propose en particulier le LinuxBIOS 
SDK, constitue d'une carte mere compatible LinuxBIOS (chipset SiS 630/730) et des outils 
de developpement logiciel associes (voir http://www.cwlinux.com/eng/products). 

Red Boot 

RedBoot est l'acronyme de Red Hat Embedded Debug and Bootstrap. RedBoot est 
derive du developpement d'eCos (Embeddable Configurable Operating System), un sys- 
teme d' exploitation temps reel a tres faible empreinte memoire developpe par Red Hat. 
RedBoot apporte des fonctions interessantes concernant des points comme le demarrage 
d'un systeme via reseau (bootp et tftpboot), la gestion de la memoire flash, le telecharge- 
ment de fichier via reseau ou ligne serie, l'execution d'un noyau Linux sur la cible ou 
bien la mise au point a distance. 

Presentation et principales commandes 

RedBoot est disponible pour un grand nombre d' architectures comme les processeurs 
StrongARM, SuperH ou x86. Le site de reference de RedBoot est situe a l'adresse http:// 
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sources.redhat.com/redboot. Une liste d'images binaires precompilers est disponible sur 
http://sources.redhat.com/eCos/boards/redbootbins. 

L' interface d' utilisation de RedBoot est relativement simple a utiliser. La documentation 
complete est disponible en ligne a l'adresse http://sources.redhat.com/eCos/docs-latest/ 
redboot/redboot.html (ou bien redboot.pdf pour la version PDF). 

La commande f conf i g permet de connaitre et modifier la configuration courante de RedBoot. 

RedBoot> fconfig -1 
Run script at boot: false 
Use BOOTP for network configuration: false 
Local IP address: 192.168.3.10 
Default server IP address: 192.168.3.1 
GDB connection port: 9000 
Network debug at boot time: false 

On peut communiquer avec RedBoot en utilisant le protocole Telnet sur le port 9000. 

$ telnet mon_redboot 9000 
Connected to mon_redboot 
Escape character is ~ A ]'. 
RedBoot> 

La configuration reseau de RedBoot s'effectue soit en specifiant une adresse IP statique, 
soit en affectant une adresse IP dynamique via le protocole BOOTP. Cela necessite la 
mise en place d'un serve ur DHCP sur le poste de developpement. II faut noter que Red- 
Boot ne supporte par le routage IP et que le poste de developpement devra etre sur le 
meme reseau que la cible supportant RedBoot. 

RedBoot permet de manipuler de la memoire flash si elle est disponible sur le systeme 
cible, et ce via le FIS (Flash Image System) et la commande f 1 s. 

IRedBoot> fis init -f 
About to initialize [format] flash image system - are you sure (y/n)? n 

La commande f i s permet egalement la manipulation de partitions sur la memoire flash (f i s 
create, f i s del ete, f i s 1 i st) ou le chargement de la memoire flash vers la RAM (f i s 1 oad). 

La commande load permet de telecharger un fichier dans la RAM depuis le poste de 
developpement via le reseau ou une connexion serie. Dans le cas d'une connexion reseau, 
le protocole TFTP est utilise. En cas de lien serie, on peut utiliser XMODEM ou YMODEM. 
Le fichier est telecharge a une adresse de la memoire RAM de la cible en utilisant l'option -b. 

RedBoot> load -b -r 0x8x210000 -m TFTP -h 192.168.3.1 bzlmage 

La commande exec permet d'executer un noyau Linux depuis la RAM. 

Un exemple complet d'utilisation 

La section qui suit presente un exemple complet d' installation et d'utilisation de Red- 
Boot sur une carte devaluation Assabet StrongARM SA1110 fournie par Intel. Lenvi- 
ronnement teste est le suivant. 
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Du cote materiel, l'experience requiert : 

• une carte Intel Assabet qui est une carte d' evaluation du 
processeur StrongARM SA1110 (voir http://developer.inte! 
.com/design/pca/applicationsprocessors/1 1 1 0_brf.htm et http: 
//developer.intel.com/design/pca/applicationsprocessors), 

• connexion JTAG (Joint Test Advisory Group) sur le port 
parallele, 

• connexion serie. 



Remarque 

La norme JTAG ou IEEE 1 1 49.1 permet de tester les parties numeriques 
des systemes, cartes electroniques et ASIC. Des informations en francais 
sur le JTAG sont disponibles sur http://www.temento.com/ftestintr.htm. 
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Figure 8-2 

Carte Assebet Intel. 



Cote logiciel, nous utilisons les composants suivants : 

• noyau Linux 2.4.18 avec patch ARM (http://www.arm.linux.org.uk), 

• distribution Familiar (disponible sur http://www.handhelds.org), 

• RedBoot. 

L'experience est composee des phases suivantes. 

1 . Recuperation, configuration et compilation de RedBoot. 

2. « Flashage » de RedBoot sur la carte grace au JTAG via le port parallele. 

3. Prise de controle de la carte via le port serie. 

4. Configuration de RedBoot sur la carte, partitionnement de la memoire flash et confi- 
guration reseau de RedBoot. 

5. Recuperation du noyau Linux via le protocole TFTP et flashage. 

6. Recuperation du systeme de fichier via TFTR puis flashage. 

7. Demarrage. 

Remarque 

Le terme « flasher » ou « flashage » ne figure certainement pas dans le dictionnaire de I'Academie frangaise. II 
est cependant bien approprie pour exprimer simplement une « ecriture dans une memoire permanente ». 



Une documentation est disponible dans les sources du noyau dans le fichier Documentati on 
/arm/SA1100/Assabet . txt. Concernant RedBoot, la documentation est disponible en ligne 
sur http://sources.redhat.com/eCos/docs-latest/redboot/redboot.html. 

II est avant tout necessaire de recuperer eCos de Red Hat car RedBoot est integre a ce 
projet. Mieux vaut telecharger la derniere version a partir de l'arborescence CVS. Les instruc- 
tions de telechargement sont disponibles sur http://sources.redhat.com/eCos/anoncvs.html. 
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Apres telechargement de eCos et extraction dans le repertoire eCos, un repertoire 
redboot_assabet est cree au meme niveau que le repertoire eCos arm d'accueillir notre 
configuration. 

# Is 

eCos redboot_assabet 

# export eCosDIR=/home/src/rh/eCos 

# export eCos_REPOSITORTY=/home/src/rh/eCos/packages 

# cd redboot_assabet 

# $eCosDIR/host/configure --prefix=$TEMP/redboot-build --with-tcl -header=/usr/ 
*include/tcl8.3/ --with-tcl -1 ib=/usr/l ib/tcl8.3 

§ make 

La configuration s'effectue ensuite comme suit : 

§ ./tools/configtool /standalone/common/eCosconfig new assabet redboot 

U CYGSEM_HAL_USE_R0M_M0NITOR, new inferred value 

U CYGDBG_HAL_COMMON_CONTEXT_SAVE_MINIMUM. new inferred value 

U CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS, new inferred value 1 

U CYGFUN_LIBC_STRING_BSD_FUNCS, new inferred value 

# ./ tools /configtool/s tandalone/common/eCosconfig 
** import $eCosDIR/packages/hal /arm/sallxO/assabet/current/misc/redboot_ROM.ecm 

# ./tools/configtool/standalone/common/eCosconfig tree 

# make 

Les binaires sont alors disponibles dans le repertoire instal 1 /bin. 



§ Is -al install /bin 
















total 1157 
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Pour flasher l'utilitaire RedBoot sur la carte, on utilise le programme Jflash developpe 
par Intel et adapte a Linux. 

# Jflash-linux instal 1 /bin/redboot. bin 

JFLASH Version 1.2 

Using LPT port at 0x378 

SA-1110 revision B4 

Number of blocks in device = 128 

Block size = 65536 0x10000 

Device size = 16777216 0x1000000 

Starting erase 
Erasing done 
Starting programming 
Programming done 
Starting verify 
Verification successful! 
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Sur une session mi ni com connectee au port serie, on obtient la trace suivante : 

Waiting for network card: No network interfaces found 

RedBoot(tm) bootstrap and debug environment [ROM] 

Non-certified release, version UNKNOWN - built 15:18:20, Jun 20 2002 

Platform: Assabet development system (StrongARM 1110) 
Copyright (C) 2000, 2001, 2002, Red Hat, Inc. 

RAM: 0x00000000-0x02000000, 0x000106c8-0x01fbd000 available 

FLASH: 0x50000000 - 0x52000000, 128 blocks of 0x00040000 bytes each. 

RedBoot> 

On doit ensuite initialiser la memoire flash et configurer RedBoot au niveau du reseau. 

RedBoot> fis init -f 

About to initialize [format] FLASH image system - are you sure (y/n)? y 

*** Initialize FLASH Image System 

... Erase from 0x50080000-0x51f80000: 



Erase from 0x51fc0000-0x51fc0000: 

Erase from 0x52000000-0x52000000: 

Unlock from 0x51fc0000-0x52000000: . 

Erase from 0x51fc0000-0x52000000: . 

Program from 0x01fbf000-0x01fbf400 at 0x51fc0000: . 

Lock from 0x51fc0000-0x52000000: . 
RedBoot> fconfig -i 

Initialize non-volatile configuration - are you sure (y/n)? y 
Run script at boot: false 
Use B0OTP for network configuration: false 
Local IP address: 10.0.0.2 
Default server IP address: 10.0.0.1 
Console baud rate: 115200 
GDB connection port: 9000 
Network debug at boot time: false 

Update RedBoot non-volatile configuration - are you sure (y/n)? y 
... Unlock from 0x51f80000-0x51f81000: . 
... Erase from 0x51f80000-0x51f81000: . 
... Program from OxOlfbeOOO-OxOlfbfOOO at 0x51f80000: . 
... Lock from 0x51f80000-0x51f81000: . 
RedBoot> 

On insere ensuite l'adaptateur Ethernet (au format CompactFlash) puis on effectue une 
initialisation de la carte. 

RedBoot> reset 

... Resetting. y u . Failed 

Socket Communications, Inc: Low Power Ethernet CF Revision C 5V/3.3V 08/27/98 

Ethernet ethO: MAC address 00:c0:lb:00:b6:al 

IP: 10.0.0.2, Default server: 10.0.0.1 
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RedBoot(tm) bootstrap and debug environment [ROM] 

Non-certified release, version UNKNOWN - built 15:18:20, Jun 20 2002 

Platform: Assabet development system (StrongARM 1110) 
Copyright (C) 2000, 2001, 2002, Red Hat, Inc. 

RAM: 0x00000000-0x02000000, 0x000106c8-0x01fbd000 available 

FLASH: 0x50000000 - 0x52000000, 128 blocks of 0x00040000 bytes each. 

RedBoot> 

On peut ensuite telecharger puis flasher le noyau et 1' image du systeme de fichiers. 
L'adresse IP 10.0.0.1 dispose d'un serveur FTP qui contient : 

• le noyau sous forme du fichier zI2418as, 

• l'image du systeme de fichier task- familiar- complete. jffs2 (extrait de la distribu- 
tion familiar disponible sur http://www.handhelds.org). 

RedBoot> load zI2418as -r -b 0x100000 
Raw file loaded 0x00100000-0x001b03a0 
RedBoot> fis create "Linux kernel" -b 0x100000 -1 OxcOOOO 

Erase from 0x50040000-0x50100000: ... 

Program from OxOOlOOOOO-OxOOlcOOOO at 0x50040000: ... 

Unlock from 0x51fc0000-0x52000000: . 

Erase from 0x51fc0000-0x52000000: . 

Program from OxOlfbfOOO-OxOlfffOOO at 0x51fc0000: . 

Lock from 0x51fc0000-0x52000000: . 
RedBoot> load task-famil iar-complete. jffs2 -r -b 0x100000 
RedBoot> load fam.jffs2 -r -b 0x100000 
Raw file loaded 0x00100000-0x00c80000 
RedBoot> fis free 

0x50100000 .. 0x51F80000 
RedBoot> fis unlock -f 0x50100000 -1 0x01E80000 
... Unlock from 0x50100000-0x51f80000: 

* RedBoot> fis erase -f 0x50100000 -1 0x01E80000 

... Erase from 0x50100000-0x51f80000: 

* RedBoot> fis write -b 0x100000 -1 0x00B80000 -f 0x50100000 

* CAUTION * about to program FLASH 
at 0x50100000.. 0x50c7ffff from 0x00100000 - are you sure (y/n)? y 

. . . Erase from 0x50100000-0x50c80000: 

... Program from 0x00100000-0x00c80000 at 0x50100000: 

* RedBoot> fis create "JFFS2" -n -f 0x50100000 -1 0x01E80000 

... Unlock from 0x51fc0000-0x52000000: . 

... Erase from 0x51fc0000-0x52000000: . 

... Program from OxOlfbfOOO-OxOlfffOOO at 0x51fc0000: . 

... Lock from 0x51fc0000-0x52000000: . 

RedBoot> 

La memoire flash est maintenant initialisee ; elle contient le noyau et le systeme de 
fichiers. 



RedBoot> fis list 
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Name 
RedBoot 

RedBoot[backup] 
RedBoot config 
FIS directory 
Linux kernel 
JFFS2 
RedBoot> 



FLASH addr Mem addr 



0x50000000 
0x50040000 
0x51F80000 
0x51FC0000 
0x50040000 
0x50100000 



0x50000000 
0x50040000 
0x51F80000 
0x51FC0000 
0x00100000 
0x50100000 



Length 

0x00040000 

0x00040000 

0x00001000 

0x00040000 

0x00000000 

0x01E80000 



Entry point 

0x00000000 

0x00000000 

0x00000000 

0x00000000 

0x00000000 

0x00000000 



On peut enfin demander a RedBoot de charger le noyau depuis la memoire flash vers la 
RAM, puis de l'executer. 

RedBoot> fis load "Linux kernel" 

RedBoot> exec -b 0x100000 -1 OxcOOOO -c "root=/dev/mtdblock4 console=ttySA0" 

Uncompressing Linux done, booting the kernel . 

Linux version 2.4.18-rmk4 (root@ebenard.boudiow.org) (gcc version 2.95.2 19991024 
*• (release)) #96 ven avr 26 20:27:19 CEST 2002 
Processor: Intel StrongARM-1110 revision 8 
Architecture: Intel -Assabet 
On node total pages: 4096 



zone(0) 
zoned) 
zone(2) 
Kernel 



4096 pages. 
pages. 
pages, 
command line: 



0, 4096 bytes) 
16384 bytes) 



root=/dev/mtdbl ock4 consol e=ttySA0 
Warning: uninitialized Real Time Clock 
Console: colour dummy device 80x30 
Calibrating delay loop... 147.04 BogoMIPS 
Memory: 16MB = 16MB total 

Memory: 14396KB available (1343K code, 279K data, 64K init) 
Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes) 
Inode-cache hash table entries: 1024 (order: 1, 8192 bytes) 
Mount-cache hash table entries: 512 (order: 0, 4096 bytes) 
Buffer-cache hash table entries: 1024 (order: 
Page-cache hash table entries: 4096 (order: 2, 
Posix conformance testing by UNIFIX 
Linux NET4.0 for Linux 2.4 

Based upon Swansea University Computer Society NET3.039 
Initializing RT netlink socket 
CPU clock: 221.200 MHz (0.000-221.200 MHz) 
S4tarting kswapd 

UCBlxOO: probed IRQ44 correctly. Please remove machine dependencies from 
** ucblxOO-core.c 
ucb : pm_register 

Sound: Assabet UDA1341: dsp id 3 mixer id 
SA1100 flash: probing 32-bit flash bus 
Using buffer write method 
Using RedBoot partition definition 
Creating 7 MTD partitions on "SA1100 flash": 



0x00000000-0x00040000 
0x00040000-0x00100000 
0x00040000-0x00080000 



"RedBoot" 
"Linux kernel " 
"RedBoot[backup]" 
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0x00080000-0x00100000 
0x00100000-0x01f80000 
0x01f80000-0x01f81000 



"unallocated space" 

"JFFS2" 

"RedBoot config" 
mtd: partition "RedBoot config" doesn't end on an erase block -- force read-only 
0x01fc0000-0x02000000 : "FIS directory" 
Linux Kernel Card Services 3.1.22 

options: [pm] 
SA-1100 PCMCIA (CS release 3.1.22) 
NET4: Linux TCP/IP 1.0 for NET4.0 
IP Protocols: ICMP. UDP, TCP 

IP: routing cache hash table of 512 buckets, 4Kbytes 
TCP: Hash tables configured (established 1024 bind 1024) 
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. 
NetWinder Floating Point Emulator V0.95 (c) 1998-1999 Rebel.com 
FAT: bogus logical sector size 408 
VFS: Mounted root (jffs2 filesystem). 
Freeing init memory: 64K 
I NIT : version 2.78 booting 
Mounting local filesystems. . . 

Pour notre carte devaluation, nous utilisons le pilote MTD, decrit au chapitre precedent, 
associe au systeme de fichier journalise JFFS2. La configuration du noyau (fichier . conf i g) 
pour la partie MTD est done la suivante : 

# 

# Memory Technology Devices (MTD) 
# 

C0NFIG_MTD=y 
C0NFIG_MTD_PARTITI0NS=y 
C0NFIG_MTD_REDB00T_PARTS=y 
C0NFIG_MTD_CHAR=y 
C0NFIG_MTD_BL0CK=y 

# 

# RAM/ROM/Flash chip drivers 
# 

C0NFIG_MTD_CFI=y 
C0NFIG_MTD_GEN_PR0BE=y 
C0NFIG_MTD_CFI_ADV_0PTI0NS=y 
C0NFIG_MTD_CFI_N0SWAP=y 
C0NFIG_MTD_CFI_GE0METRY=y 
C0NFIG_MTD_CFI_B4=y 
C0NFIG_MTD_CFI_I2=y 
CONFIG_MTD_CFI_INTELEXT=y 

# 

# Mapping drivers for chip access 

C0NFIG_MTD_SA1100=y 
# 

# File systems 
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C0NFIG_JFFS2_ 
C0NFIG_JFFS2_ 



FS=y 
FS_DEBUG=0 



Pour le demarrage, on obtient les traces suivantes : 

<5>SA1100 flash: probing 32-bit flash bus 
<7>0: offset=0x0,size=0x40000,blocks=128 
<4>Using buffer write method 
<5>Usi ng RedBoot partition definition 
<5>Creating 7 MTD partitions on "SA1100 flash": 



<5>0x00000000-0x00040000 
<5>0x00040000-0x00100000 
<5>0x00040000-0x00080000 
<5>0x00080000-0x00100000 
<5>0x00100000-0x01f80000 
<5>0x01f80000-0x01f81000 



RedBoot" 

Linux kernel " 

RedBoot[backup]" 

unallocated space" 

JFFS2" 

RedBoot config" 

<4>mtd: partition "RedBoot config" doesn't end on an erase block 
<5>0x01fc0000-0x02000000 : "FIS directory" 



force read-only 



On note la detection des memoires flash (2 x 128 Mbits, chacune sur 16 bits de largeur 
de donnees, l'association des deux formant done un bus de 32 bits) par la couche MTD, 
puis la lecture des partitions de RedBoot stockees dans la partition FIS directory. Cha- 
cune des partitions est accessible a travers /dev/mtdblockX. 



# cat /proc/mtd 

dev: size erasesize 

mtdO: 00040000 00040000 ' 

rntdl: OOOcOOOO 00040000 ' 

mtd2: 00040000 00040000 ' 

mtd3: 00080000 00040000 ' 

mtd4: 01e80000 00040000 ' 

mtd5: 00001000 00040000 ' 

mtd6: 00040000 00040000 ' 



name 
RedBoot" 
Linux kernel" 
RedBoot[backup] " 
unallocated space" 
JFFS2" 

RedBoot config" 
FIS directory" 



En resume 



L' utilisation d'un disque memoire peut etre conseillee dans le cas d'un systeme de petite 
taille qui ne doit pas sauvegarder de donnees durant son execution. L'utilisation d'une 
image de root file system compressee est cependant assez contraignante durant la phase 
de developpement de par les nombreux transferts qui sont effectues entre le poste de 
developpement et la cible. 

Linux fournit en standard des outils de mise au point de programme comme gdb, strace 
ou efence. Gdb permet aussi de mettre au point un programme a distance sur une cible 
connectee via reseau ou cable serie. 

LinuxBIOS est un projet Open Source destine a remplacer le BIOS standard qui n'est pas 
utilise par le noyau Linux. RedBoot est un outil puissant pour parer au developpement et 
a la mise au point sur de nombreuses architectures. 



Troisieme partie 



Mises en oeuvre 
particulieres 




Cette partie decrit quelques techniques specifiques de l'environ- 
nement embarque sous Linux. Plusieurs chapitres seront consacres 
a des versions speciales de Linux comme Ies extensions temps-reel 
(RTLinux et RTAI) et la version pour micro-controleur uClinux. 
Un chapitre est consacre a la mise en oeuvre d'interfaces graphiques 
adaptees. Pour finir, un chapitre sera dedie a 1'utilisation d'environ- 
nements de developpement croise utilisables sur des plates-formes 
Linux et Windows et permettant de developper et de mettre au 
point du code sur des cibles embarquees. 



9 



Systemes temps reel 



Dans ce chapitre, on va s'attacher a decrire les principales solutions autorisant la mise en 
place d'une solution Linux pour un environnement temps reel. Le chapitre 1 a introduit 
de maniere generale les concepts d'un systeme « temps reel » par opposition a un sys- 
teme dit a « temps partage ». Nous rappellerons tout d'abord qu'il existe deux types de 
systemes temps reel : 

• Les systemes dits temps reel « mous » ou « souples » {soft real time) pour lesquels les 
contraintes temps reel ne sont pas tres fortes et surtout ou le non-respect de l'echeance 
temporelle ne met pas en peril le systeme ni 1' environnement. On parlera de temps de 
reponse d'« environ X unites de temps ». Ces systemes peuvent se rapprocher d'un 
systeme classique comme Linux, ce dernier pouvant acquerir ce type de fonctionnali- 
tes apres quelques modifications simples du noyau. lis respectent en general des delais 
de reponse assez importants, de l'ordre de la milli-seconde. 

• Les systemes dits temps reel « durs » {hard real time) pour lesquels le respect de 
l'echeance temporelle est indispensable. Dans la plupart des cas, ces systemes doivent 
egalement respecter les contraintes les plus fortes au niveau du delai de reponse (quel- 
ques dizaines de micro-secondes, parfois moins). 

Tests sur un noyau Linux standard 
Horloge temps reel /dev/rtc 

Un noyau Linux standard dispose d'une horloge « temps reel » a travers le device /dev/ 
rtc {Real Time Clok) associe a l'interruption de niveau 8. L'utilisateur peut se servir de ce 
device pour programmer une alarme ou une interruption periodique. Le fichier Documen- 
tati on/rtc . txt des sources du noyau 2.4 donne une description precise des possibilites 
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de cette horloge. Le document contient egalement un petit programme de test rtctest . c. 
Apres compilation, l'execution du programme donne le resultat suivant : 



# ./rtctest 



RTC Driver Test Example. 



Counting 5 update (1/sec) interrupts from reading /dev/rtc: 12 3 4 5 
Again, from using select(2) on /dev/rtc: 12 3 4 5 

Current RTC date/time is 25-5-2002, 15:04:28. 

Alarm time now set to 15:04:33. 

Waiting 5 seconds for alarm... okay. Alarm rang. 

Periodic IRQ rate was 1024Hz. 
Counting 20 interrupts at: 



2Hz: 


1 2 3 4 5 6 7 8 9 10 11 


12 


13 14 


15 


16 


17 


18 19 20 


4Hz: 


1 2 3 4 5 6 7 8 9 10 11 
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16 
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18 19 20 


8Hz: 


1 2 3 4 5 6 7 8 9 10 11 
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16Hz: 


1 2 3 4 5 6 7 8 9 10 11 
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32Hz: 


1 2 3 4 5 6 7 8 9 10 11 
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16 
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18 19 20 


64Hz: 


1 2 3 4 5 6 7 8 9 10 11 
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13 14 
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18 19 20 



*** Test complete *** 

Typing "cat /proc/interrupts" will show 131 more events on IRQ 8. 

L utilisation de /dev/rtc ne pose pas de probleme lorsque le systeme est raisonnable- 
ment charge. Quand le systeme est trop charge, on constate de plus en plus de pertes 
d' interruption, et ce en fonction de la puissance du processeur et de la charge. Le docu- 
ment rtc.txt cite deja des pertes d' interruption sur un 486-33 MHz au-dela d'une fre- 
quence de 1024 Hz. Pour evaluer les performances d'un noyau Linux du point de vue du 
respect des contraintes temps reel, nous pouvons utiliser les outils latencytest et realfeel. 



L'outil latencytest 



L'outil latencytest (http://www.gardena.net/benno/linux/audio) est constitue d'une suite de 
programmes destines a evaluer les problemes de temps de latence sur un noyau Linux. La 
commande latencytest permet de jouer un echantillon sonore avec ou sans charge du 
systeme. Un autre programme rtc_latencytest permet d'evaluer le comportement de 
l'horloge temps reel precedemment decrite. L'outil permet de provoquer une charge du 
systeme au niveau affichage graphique (XI 1), acces a /proc et acces disque. 



L'outil realfeel 



Cet outil est inclus dans le paquetage amlat disponible sur http://www.zip.com.au/~akpm/ 
linux/schedlat.html. La commande real feel utilise l'horloge temps reel /dev/rtc afin de 
generer une sollicitation a 2048 Hz. La periode donne le temps de reponse theorique du 
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systeme et chaque point de mesure represente le temps de latence entre la valeur theori- 
que et la valeur reelle. Les resultats sont stockes dans un simple fichier d'historique qui 
permet de generer des graphiques en utilisant l'outil gnuplot (http://www.gnuplot.info). 

Pour forcer la charge du systeme, on utilise les programmes crashme et burnMMX extraits 
de la suite Open Source CTCS (Cerberus Test Control System) disponible sur http:// 
sourceforge.net/projects/va-ctcs. Une suite d'outils similaires existe egalement sous forme 
de paquetage RPM disponible sur http://people.redhat.com/bmatthews/cerberus. 



Resultats du test 



Les tests sont effectues sur un AMD Duron 700 MHz equipe de 360 Mo de memoire vive. 
L'utilisation de real feel sur cinq millions d'iterations (interruptions /dev/rtc) indique 
des temps de latence importants dans certains cas. La majorite des valeurs (plus de 
99,97 %) se situe avant 5 ms mais quelques points se positionnent au-dela de 230 ms. 



le + 06 
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Figure 9-1 

Mesure avec realfeel sur un noyau standard charge. 
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maximum latency: 232.6ms 
Mean: 0.0883230599960576ms 
Standard Deviation: 2.11903578618566 
92.84442% of samples < 0.1ms 
97.08432% of samples < 0.2ms 
99.73050% of samples < 0.5ms 
99.84382% of samples < 0.7ms 
99.94038% of samples < 1ms 
99.97922% of samples < 5ms 
99.98096% of samples < 10ms 
99.98590% of samples < 50ms 
99.98828% of samples < 100ms 
100.00000% of samples < 232.7ms 



Les d if fe rentes approches temps reel pour Linux 

Le premier constat est sans appel. Linux dans sa version standard n'est pas un systeme 
temps reel mais un systeme a temps partage. Meme s'il fait une remarquable percee dans 
le monde des systemes industriels et embarques, il a ete initialement concu pour equiper 
des systemes generalistes, en particulier des serveurs, pour lesquels la gestion du temps 
est totalement differente, le but d'un systeme a temps partage etant de donner une 
impression de contort a ses utilisateurs. Tous les systemes embarques ne necessitent pas 
de contraintes temps reel et nous avons vu que, quand Linux est correctement dimen- 
sionne dans un environnement d' applications connues, les temps de reponse sont a peu 
pres stables. Si cette situation est satisfaisante pour 1' application envisagee, nous pour- 
rons facilement utiliser un noyau standard. 

Si les contraintes de temps de reponse deviennent plus importantes, il faudra utiliser une 
version modifiee du noyau Linux. Les modifications peuvent etre de deux types. 



Modification de I'ordonnanceur 

Lordonnanceur Linux utilise trois types algorithmes possibles (policies). Ces algorith- 
mes sont identifies par les valeurs SCHED_RR, SCHED_FI FO et SCHED_OTHER. Le type SCHED_ 
OTHER est utilise pour les taches non temps reel. Le type SCHEDD_RR utilise un algorithme 
de partage du temps associe a une valeur de priorite. Lorsque la tache a termine son quan- 
tum de temps, elle est placee de nouveau dans la file d'attente correspondant a sa priorite, 
et on lui alloue un nouveau quantum. Le type SCHED_FIFO n' utilise pas la notion de 
quantum de temps et la tache est executee tant qu'elle n'est pas bloquee par une demande 
de ressource. Pour definir une tache a la plus haute priorite possible, on peut utiliser le code 
suivant, qui est d'ailleurs repris par des outils de mesure comme latencytest et realfeel. 

int set_real time_priority(void) 



f 



struct sched_param schp; 
/* 
* set the process to realtime privs 
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*/ 
memset(&schp, 0, sizeof (schp) ) ; 
schp.schecLpriority = sched_get_priority_max(SCHED_FIFO) ; 

if (sched_setscheduler(0, SCHED_FIF0, &schp) != 0) { 
perror("sched_setscheduler" ) ; 
exit(l); 



return 0; 
} 



Cela etant dit, l'ordonnanceur Linux standard n'a pas la granularite necessaire a une ges- 
tion de taches similaire a celle d'un noyau temps reel pour lequel les taches sont gerees 
par des niveaux de priorite fixes. 

La premiere approche consiste a modifier le systeme de gestion du temps a l'interieur de 
noyau (ordonnanceur ou scheduler) de maniere a ameliorer le niveau de preemption et 
done se rapprocher d'un comportement d' ordonnanceur temps reel. La solution utilisee 
par cette approche est d'ajouter des « points de preemption » de maniere a verifier le plus 
souvent possible si le passage a une tache de plus haute priorite est necessaire ; la fonc- 
tion d'ordonnancement schedule est done executee plus souvent. Cette solution est dis- 
ponible sous forme du patch kernel-preempt pour le noyau 2.4 et elle est integree au 
noyau 2.6. La societe Monta Vista (http://www.mvista.com), specialisee dans la diffusion 
de solutions Linux embarquees, est a l'origine de ce developpement qui est disponible en 
Open Source. 

Une approche similaire, presentant cependant quelques differences, est celle du patch 
low-latency qui, au lieu d'ajouter systematiquement des points de preemption, les place a 
des points strategiques bloquant l'appel a l'ordonnanceur pendant une duree non negli- 
geable. La difficulte dans cette approche reste d'identifier correctement les points en 
question. Toutefois, cette strategie a l'avantage de limiter la chute de performance que 
pourraient provoquer un trop grand nombre d'appels a l'ordonnanceur. 

Ces solutions ont surtout le gros avantage de ne pas modifier 1' interface de programma- 
tion des applications car tout est fait au niveau du noyau et les developpeurs travaillent 
toujours en mode utilisateur (et non en mode noyau), ce qui est une garantie de stabilite 
du systeme, une tache utilisateur ne pouvant pas « planter » le noyau. En revanche, elles 
ont 1' inconvenient de necessiter des modifications dans un noyau qui n'est pas concu au 
depart pour un ordonnancement temps reel des taches. 

Meme si les resultats obtenus sont encourageants (voir a la fin du chapitre), il est judi- 
cieux de reserver cette technique a des systemes a contraintes temps reel souples. 

Ajout d'un veritable noyau temps reel 

La seconde approche est celle defendue par les projets RTLinux (http://www.fsmlabs.com) 
et RTAI (http://www.rtai.org). Le principe simple qui y preside est de considerer que le 
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noyau Linux n'est pas concu pour traiter des taches temps reel et done d'ajouter au 
systeme un noyau temps reel partageant la memoire avec le noyau Linux. Ce noyau 
temps reel s'intercale entre le materiel et le noyau Linux de maniere a recuperer les inter- 
ruptions materielles. Les fonctions comme cli() ou sti() sont rederinies de maniere a ce que 
toutes les interruptions soient prealablement traitees par la partie temps reel. Les pilotes 
standards du noyau Linux continuent a fonctionner mais ils doivent etre recompiles s'ils 
utilisent des fonctions liees aux interruptions. Si les pilotes doivent assurer des fonctions 
temps reels, ils doivent egalement etre adaptes pour RTLinux. La distribution RTLinux/GPL 
fournit en exemple la version temps reel rt_com d'un pilote de port serie. 

Le noyau temps reel est bien sur preemptif et utilise un ordonnanceur qui contrairement 
au noyau Linux est base sur la notion de priorite fixe. Les services habituels d'un systeme 
Linux sont toujours traites par le noyau standard mais les taches temps reel (et seulement 
celles-ci) sont traitees par le noyau temps reel. Pour ce dernier, le noyau Linux est consi- 
dere comme une tache de « plus faible priorite » {idle task). Le synoptique d'un tel systeme 
est presente ci-apres sous forme de schema. 



Espace utifisateur 



[ Processus Linux 

L (recuperation de donnees) J 



Processus Linux 



(MM) 



Tache 
temps reel 3 

application 
A i 
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module sched 
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Linux 



^ Handlers d 1 IT Linux 



T Iaterrution logjcielles j 
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Noyau temps reel : RTLinux 



Materiel - contraleur d' interruptions 



Figure 9-2 

Architecture RTLinux. 



Les taches temps reel sont des modules au sens Linux du terme et done executees dans le 
meme espace que le noyau Linux (espace noyau et non espace utilisateur). Ce point est 
tres interessant au niveau des performances mais cela implique qu'une tache temps reel 
mal programmee peut etre fatale au systeme. Les taches temps reel sont des threads ou 
« processus legers » au niveau noyau (kernel threads), la programmation de ces threads 
est conforme a la norme Posix.lc. En raison de l'utilisation de deux noyaux, le systeme 
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est tres performant et le temps de reponse entre l'arrivee de 1' interruption et le demarrage 
de la fonction associee est couramment inferieur a 15 micro-secondes. 

D'une maniere generale, la programmation dans l'espace noyau doit etre imperativement 
limitee aux taches temps reel. Tout service qui n'a pas de contrainte temps reel doit utili- 
ser le noyau Linux standard. 

Dans la suite du chapitre, on s'attachera a decrire quelques exemples illustrant les con- 
cepts exposes ici. Nous allons maintenant decrire en detail l'utilisation de RTLinux et 
RTAI, puis evoquer quelques patches preemptifs pour le noyau Linux. 

L'outil de test rt_realfeel 

L'outil rt_realfeel est une adaptation « maison » de l'outil realfeel cite precedemment. II 
est utilise pour evaluer les temps de latence dans le cas des systemes Linux temps reel 
durs de type RTLinux ou RTAI. Le principe en est de generer une tache periodique par la 
fonction pthread_make_peri odi c_np. La periode donne le temps de reponse theorique du 
systeme et chaque point de mesure represente le temps de latence entre la valeur theori- 
que et la valeur reelle. Un fichier historique de meme type que celui de realfeel est genere 
a la fin de l'execution. 



Utilisation de RTLinux 

RTLinux est un projet Open Source issu des travaux de Victor Yodaiken et Michael Bara- 
banov a l'universite du Nouveau-Mexique aux Etats-Unis. Les deux createurs du projet 
ont depuis cree la societe FSMLabs (http://www.fsmlabs.com) qui, en plus de la version 
GPL (RTLinux/GPL), fournit une version commerciale de RTLinux (RTLinux/Pro) ainsi 
que du support. Le projet est depuis toujours disponible sous GPL mais un brevet 
(patent) est lie au concept du double noyau de RTLinux. La licence d'utilisation de la 
version GPL est tres claire a ce sujet. L'utilisation de RTLinux/GPL n'entraine pas le 
paiement de droits d'utilisation a partir du moment ou ce dernier est utilise dans un projet 
lui-meme diffuse sous GPL. Si le projet n'est pas diffuse sous GPL, il est necessaire 
d'utiliser la RTLinux/Pro qui est egalement livree avec les sources, qui ne sont cependant 
pas redistribuables comme c'est bien entendu le cas pour RTLinux/GPL. Les details du 
brevet sont disponibles a l'adresse http://www.fsmlabs.com/about/patent. 

RTLinux est clairement un produit oriente industrie et la documentation disponible sur le 
site de FSMLabs est tres complete. Une FAQ traitant des domaines techniques et juridi- 
ques est disponible en ligne sur http://www.fsmlabs.com/products/faq.htm ou bien sous 
forme PDF sur la distribution de RTLinux/GPL. RTLinux est disponible pour les archi- 
tectures x86, PowerPC, Alpha et MIPS. 

Une version reduite de RTLinux (MiniRTL) est egalement disponible. Elle est basee sur 
un noyau Linux 2.2, RTLinux 2.0, et tient sur une seule disquette 1,44 Mo. MiniRTL est 
disponible en telechargement sur ftp://ftp.fsmlabs.com/pub/rtlinux/minirtl. 
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Installation de RTLinux/GPL 

La version 3.1 de RTLinux/GPL est disponible en telechargement sur ftp://ftp.fsmlabs. 
com/pub/rtlinux/v3. Dans la suite du chapitre, nous avons utilise l'archive rtlinux- 
3.1. tir. gz. La distribution se compose d'un patch a appliquer au noyau 2.4.4 ou au 
noyau 2.2.19 (versions supportees par RTLinux/GPL), des sources du noyau temps reel, 
de la documentation et de plusieurs exemples d' utilisation. Le fichier Instal 1 ati on .txt 
decrit, en anglais, la procedure d' installation. 

L' installation s'effectue dans le repertoire /usr/src de maniere a obtenir un repertoire 
/usr/src/rtlinux-3.1 apres extraction de l'archive. On peut egalement positionner un 
lien symbolique. 

Icd /usr/src 
tar xzvf /tmp/rtl inux-3.1.tar.gz 
In -s rtlinux-3.1 rtlinux 

II est egalement necessaire de recuperer le noyau Linux version 2.4.4 et d'extraire ce der- 
nier dans le repertoire /usr/src/rtlinux-3.1. Nous rappelons que les sources des 
noyaux Linux officiels sont disponibles sur ftp://ftp.kernel.org. En France, le miroir ftp:// 
ftp.free.fr/mirrors/ftp.kernel.org/linux/kernel/v2. 4 est tres efficace. Lorsque l'archive linux- 
2.4.4.tar.bz2 est disponible, on l'extrait dans le repertoire adequat, ce qui a pour effet 
de creer le repertoire 1 i nux. 



I 



cd /usr /src/rtl inux-3. 1 

tar xjvf /tmp/linux-2.4.4.tar.bz2 



Attention 

RTLinux/GPL est prevu pour utiliser la version officielle du noyau Linux et non les versions modifiees distributes 
par les editeurs comme Red Hat. 



On doit ensuite appliquer le patch RTLinux au noyau 2.4.4, soit : 

Icd /usr/src/rtl inux-3. 1/1 inux 
patch -pi < . ./kernel-patch-2.4.4 

La prochaine etape est de configurer le noyau Linux comme decrit au chapitre 4 en utili- 
sant make xconf ig (ou bien menuconfig ou config). Pour cela, on fait : 

Icd /usr/src/rtl inux-3. 1/1 inux 
make xconf ig 

On doit alors valider les options necessaires pour le systeme actuel (independamment de 
RTLinux). Loption CONFIG_RTLINUX ajoutee par le patch est validee automatiquement 
dans le cas d'une architecture x86 ou PowerPC. 



Remarque 

II est important de ne pas valider le support APM car celui-ci peut interferer avec RTLinux. 
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On peut ensuite compiler le nouveau noyau en appliquant la procedure classique. 

make dep 

make clean 

make bzlmage 

make modules 

puis installer le noyau 

Icp arch/i'386/boot/bzlmage /boot/bzImage-2.4.4_rtl 
make modules_install 

et enfin ajouter l'entree dans le fichier /etc/1 i 1 o . conf , puis valider par un appel a /sbi n/ 
lilo. 

image=/boot/bzImage-2.4.4_rtl 
label =rtlinux 
read-only 
root=/dev/hda3 

II faut ensuite redemarrer le systeme en choisissant cette nouvelle image rtlinux. Lorsque 
le systeme a redemarre, il convient de verifier que le fonctionnement classique est tou- 
jours correct. Si c'est le cas, on peut passer a la configuration puis a la generation du 
noyau temps reel. Pour ce faire, la procedure est similaire a celle utilisee pour le noyau 
Linux, soit : 

make xconfig 

make 

make devices 

make install 

Cela a pour effet d'installer la distribution binaire sur /usr/rtl inux qui est un lien sym- 
bolique vers /usr/rtl inux-3.1. 

La partie configuration utilise une interface graphique similaire a celle du noyau Linux. 
La partie Drivers permet de valider et configurer certaines fonctionnalites de communi- 
cation decrites plus loin dans le chapitre. 
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Figure 9-3 

Configuration des drivers RTLinux. 
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Les exemples d' applications sont egalement installes dans ce repertoire. Le repertoire 
contient egalement le fichier rtl .mk qui pourra etre inclus dans le fichier Ma kef i 1 e d'une 
application RTLinux afin d'ajouter les chemins d'acces aux fichiers d'en-tete C et 
options de compilation. 

Pour terminer 1' installation, il est conseille de la tester avec le traditionnel programme 
Hello World. Avant d'executer un programme RTLinux, il est necessaire de charger les 
modules correspondant au noyau temps reel, soit : 

# /usr/src/rtl inux/bin/rtlinux start 
Scheme: (-) not loaded, (+) loaded 

(+) mbuff 

(+) psc 

(+) rtl_f1fo 

(+) rtl 

(+) rtl_posixio 

(+) rtl_sched 

(+) rtl_time 

ou bien : 

/usr/src/rtl inux/bin/rtl inux start nom_de_programme 

A ce stade, on peut verifier la presence des modules au moyen de lsmod ou rtl inux 
status. 

# 1 smod 
Module 
psc 

rtl_fifo 
rtl_posixio 
rtl_sched 
rtl_time 
rtl 

mbuff 
nf s 
lockd 
sunrpc 
eeprolOO 
rtc 

# rtl inux status 

Scheme: (-) not loaded, (+) loaded 
(+) mbuff 
(+) psc 
(+) rtl_fifo 
(+) rtl 

(+) rtl_posixio 
(+) rtl_sched 
(+) rtl_time 



Size 


Used by 


18816 





(unused) 


9952 





[psc] 


7168 





[rtl_fifo] 


43104 





[psc] 


9984 





[psc rtl_posixio rtl_sched] 


27200 





[psc rtl _f i f o rtl_posixio rtl_sched rtl_time] 


6380 





(unused) 


50792 


1 


(autoclean) 


39284 


1 


(autoclean) [nfs] 


66000 


1 


(autoclean) [nfs lockd] 


16656 


1 




6552 





(autoclean) 
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Pour tester le programme hel 1 o, il suffit de faire : 

cd /usr/src/rtl inux/examples/hel lo 

make test 

This is the simplest RTLinux program 

First we remove any existing rtl -modules 

You may see error warnings from "make" - ignore them 

Type <return> to continue 

rmmod sound 

rmmod: module sound is not loaded 

make: [test] Erreur 1 (ignoree) 

rmmod rt_process 

rmmod: module rt_process is not loaded 

make: [test] Erreur 1 (ignoree) 

rmmod frank_module 

rmmod: module frank_module is not loaded 

make: [test] Erreur 1 (ignoree) 

(cd ../../; scripts/rmrtl ) 

Now insert the fifo and scheduler 

Type <return> to continue 

(cd ../../; scripts/insrtl ) 

Now start the real-time tasks module 

La trace de l'execution est alors visible dans le fichier /var/1 og/messages ou bien avec 
la commande dmesg. 

mbuff: kernel shared memory driver vO.7.2 for Linux 2.4.4-rtl 

mbuff: (C) Tomasz Motylewski et al . , GPL 

mbuff: registered as MISC device minor 254 

RTLinux Extensions Loaded (http://www.fsmlabs.com/) 

I 'm here; my arg is 

I 'm here; my arg is 

I 'm here; my arg is 

On peut ensuite terminer 1' application, ce qui correspond au dechargement du module 
associe. 

I Now let's stop the application 
, Type <return> to finish 

Comme indique precedemment, l'execution peut egalement etre lancee, puis stoppee, 
plus simplement au moyen de la commande rtl inux. 

Irtlinux start hello 
rtlinux stop hello 

Introduction a I'API RTLinux 

La documentation complete de l'API RTLinux est disponible en ligne au me me endroit 
que la distribution RTLinux/GPL. Cette documentation est egalement accessible a l'adresse 
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http://www.fsmlabs.com/developers/man_pages. Un document GettingStarted dormant les 
informations indispensables au demarrage sous RTLinux est disponible a la meme adresse. 

Un exemple simple : Hello World 

Comme cela a ete deja vu, la programmation de modules RTLinux s'effectue dans 
l'espace noyau en utilisant la technique des processus legers Posix. Le source hello.c 
du programme precedemment utilise donne la structure minimale d'un programme 
RTLinux. 

Tout comme un module chargeable pour le noyau Linux, un module RTLinux est consti- 
tue de deux entrees init_module et cleanupjnodule. 

int init_module(void) { 

return pthread_create (&thread, NULL, start_routine, 0); 
} 

void cleanup_module(void) { 

pthread_delete_np (thread); 
} 

L' entree init_module effectue le demarrage du thread principal associe a la fonction 
start_routine( ). La seule maniere d'arreter une application RTLinux est de decharger 
le module associe. La fonction cleanup_module contient done l'appel a la fonction de 
destruction du thread. On pourrait egalement faire : 

void cleanup_module(void) { 

pthread_cancel (thread); 

pthread_join (thread, NULL); 
} 

Tout comme pour 1' utilisation des threads Posix dans l'espace utilisateur, il est necessaire 
d'effectuer un pthread_join sur le thread arm de liberer l'espace memoire alloue. 

Le code source de la fonction start_routine est donne ci-apres. 

void * start_routine(void *arg) { 
struct sched_param p; 

/* Init de la priorite a 1 */ 

p.sched_priority = 1; 

pthread_setschedparam (pthread_self ( ) , SCHED_FIF0, &p); 

/* Appel de 1 'ordonnanceur toutes les 500 us */ 
pthread_make_periodic_np (pthread_self ( ) , gethrtimeO, 

500000000); 

/* Boucle infinie d'execution de la tache */ 
while (1) { 

/* Attente de 1 'ordonnanceur */ 

pthread_wait_np( ) ; 
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/* Affichage du message */ 

rtl_printf ( "I 'm here; my arg is %x\n", (unsigned) arg); 
} 

return 0; 
} 

La premiere partie de la fonction fixe la valeur de la priorite a 1. L'appel a pthreadjnake_ 
peri odi c_np indique a l'ordonnanceur d'executer le thread selon une periode de 500 us. 
La suite constitue le corps de l'execution du thread, la fonction pthread_wait_np blo- 
quant l'execution du thread jusqu'a un nouvel appel de l'ordonnanceur (soit pendant 
500 us). L'appel a rtl_printf affiche simplement un message dans le systeme de trace 
du noyau, soit /var/log/messages ou dmesg. 

Au niveau du fichier Makef i 1 e, il est necessaire d'inclure le fichier rtl .mk genere lors de 
1' installation de RTLinux de maniere a definir correctement les chemins d'acces des en- 
tetes et definitions. Le Makef i 1 e pour l'application aura done Failure suivante : 

all: hel lo.o 

include . ./. ./rtl .mk 

clean: 
rm -f *.o 

Communication inter-process (IPC) 

Comme nous l'avons dit precedemment, la structure de RTLinux conduit a developper 
les applications en deux parties. La partie temps reel est definie dans l'espace du noyau 
mais doit etre la plus courte et efficace possible. Elle correspond a un module du type 
precedemment decrit dans l'exemple Hello World. La partie noyau est souvent associee a 
une partie executee en mode utilisateur. Cette partie ne subit pas de contraintes temps 
reel car elle utilise le noyau Linux standard. II existe divers moyens de communication 
entre la partie noyau et la partie utilisateur. L'ensemble de ces composants est appele 
RTLinux IPC (RTLinux Inter Process Communication). 

Le premier type de composant est la FIFO qui est similaire aux « tubes nommes » utilises 
dans la programmation Linux classique. La FIFO est un canal de communication unidi- 
rectionnel et il est done necessaire d'utiliser deux FIFO pour etablir une communication 
bidirectionnelle entre un module et une application utilisateur. Les FIFO sont associees a 
des devices en mode caractere, crees lors de 1' installation de RTLinux par la commande 
make devices. 



# Is -1 /dev/ 


rtf[0-5] 












crw-r--r-- 


1 root 


root 


150, 


mai 


22 


15:05 /dev/rtfO 


crw-r--r-- 


1 root 


root 


150, 


1 mai 


22 


15:05 /dev/rtfl 


crw-r--r-- 


1 root 


root 


150, 


2 mai 


22 


15:05 /dev/rtf2 


crw-r--r-- 


1 root 


root 


150, 


3 mai 


24 


17:28 /dev/rtf3 


crw-r--r-- 


1 root 


root 


150, 


4 mai 


22 


15:05 /dev/rtf4 


crw-r--r-- 


1 root 


root 


150, 


5 mai 


22 


15:05 /dev/rtf5 
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L' installation de RTLinux/GPL cree par defaut 64 FIFO (rtf a rtf 63). On peut cepen- 
dant augmenter cette valeur dans la procedure de configuration make xconfig. Cote 
noyau, les FIFO sont creees en utilisant les fonctions suivantes de l'API RTLinux, les- 
quelles doivent etre appelees dans la fonction Ini t_modul e. 

|#include <rtl_fifo.h> 
int rtf_create(unsigned int fifo, int size); 
i nt rtf_destroy( unsigned int fifo); 

On doit egalement associer une fonction de traitement (handler) a la reception de don- 
nees sur la FIFO. Pour ce faire, on fait appel a la fonction suivante : 

|#include <rtl_fifo.h> 
int rtf_create_handler(unsigned int fifo, int (* handler) O); 

Cote utilisateur, la FIFO est utilisee comme un fichier classique : 

I int fd_fifo 
fd_fifo = open C'/dev/rtfO", 0_WR0NLY); 

Lorsque le descripteur de fichier est cree, on peut bien sur effectuer les actions habituel- 
les comme read, wri te ou bien sel ect. Le petit exemple suivant est une version modifiee 
du programme de test hel 1 o. Le thread noyau se met en attente de caractere sur la FIFO 
/dev/rtfO ; a reception d'un caractere, le thread est reveille par l'ordonnanceur et affi- 
che un message. 

Les fonctions init_module et cleanup_module ont maintenant 1' allure suivante : 

int initjnodule(void) { 

int f; 

rtf_destroy (0); 

f = rtf_create (0, 100); 

rtf_create_handler(0, &my_fifo_handler) ; 

return pthread_create (&thread, NULL, start_routine, 0); 
} 

void cleanup_module(void) { 

rtf_destroy(0) ; 

pthread_delete_np (thread); 
} 

Le handler de la FIFO est appele sur reception d'un caractere. II se resume simplement a 
la lecture du caractere (grace a la fonction rtf_get) puis au reveil du thread principal. 

int my_fifo_handler (unsigned int fifo) 
{ 
int err; 



while ((err = rtf_get (0, &c, D) = 
rtl_printf ( "my_fifo_handler: got 
pthread_wakeup_np (thread); 

} 



1) 



£c\n", c, c); 
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if (err != 0) 

return -EINVAL; 
else 

return 0; 
} 

La fonction start_routi ne se contente d'afficher un message au reveil. 

void * start_routine(void *arg) 
{ 

struct sched_param p; 

p.sched_priority = 1; 

pthread_setschedparam (pthread_self ( ) , SCHED_FIF0, &p); 

while (1) { 

pthread_wait_np (); 

rtl_printf ("start_routine: Got char %x\n", c); 
) 

return 0; 
} 

Un exemple un peu plus complet d' utilisation des FIFO est disponible dans les sources 
de RTLinux dans le repertoire examples/frank. 

Le deuxieme type de composant est la memoire partagee, ou shared memory. L' utilisa- 
tion de memoire partagee est interessante lorsque le debit des donnees est superieur aux 
possibilites des FIFO explicitees precedemment. Des mesures concernant ce debit don- 
nent environ 44 Mb/s pour un Pentium, 200 MHz et 137 Mb/s pour un AMD Athlon 
800 MHz. Ces debits sont interessants mais certaines cartes de mesure peuvent generer 
des debits de l'ordre de 40 Mb/s ou plus, ce qui se situe a la limite des possibilites des 
FIFO. Le concept de memoire partagee entre deux processus utilisateur existe sous Linux 
depuis longtemps (voir man shmop) ; il est utilise pour la communication entre le serveur 
X Window et les clients dans le cas d'une station de travail. Le partage de memoire sous 
RTLinux s'effectue entre un module noyau et une application utilisateur. 

L'acces a la memoire partagee etait initialement assez complexe ; un document en expli- 
que la procedure a l'adresse http://www.isd.cme.nist.gov/projects/emc/shmem.html. Pour 
simplifier les choses, il est plutot recommande d'utiliser le pilote mbuff livre avec la ver- 
sion 3 de RTLinux/GPL. Les sources du pilote sont disponibles sur /usr/src/rtl inux/ 
drivers/mbuff. Ann de pouvoir utiliser le pilote, le support doit etre valide lors de la 
configuration de RTLinux par make xconf i g. Le pilote est associe a la presence du device 
/dev/mbuff. 

I# Is -1 /dev/mbuff 
crw-r--r-- 1 root root 10, 254 mai 22 15:05 /dev/mbuff 

L'utilisation de mbuff est tres simple et basee sur deux fonctions principales d'allocation 
et de liberation. 

|#include <mbuff.h> 
void * mbuff_alloc(const char *name, int size); 
void mbuff_free( const char *name, void * mbuf); 
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Cote module noyau, on doit allouer le segment de memoire partagee dans la fonction 
init_module. Le segment sera libere dans cleanup_module. 

F volatile int* shm_ptr; 
#define SHRMEM_NAME "mbufftest" 

int init_module(void){ 

if((shm_ptr = (volatile int*) mbuff_al loc(SHRMEM_NAME,sizeof (int) ) ) == NULL) 
{ 

rtl_printf("MBUFF_ALLOC FAILED\n"); 

return -1; 
} 

return pthread_create (Hthread, NULL, routine, 0) ; 
} 

void cleanup_module(void) 
{ 

pthread_delete_np( thread) ; 

mbuff_free(SHRMEM_NAME,(void*)shm_ptr); 
} 

Dans notre exemple, le thread principal effectue simplement une incrementation du con- 
tenu de la memoire pointee par shm_ptr au fur et a mesure de l'execution. 

void* routineCvoid* t) 
{ 

struct sched_param p; 

p.sched_priority = 1; 

pthread_setschedparam (pthread_self ( ) , SCHED_FIFO, &p); 

*shm_ptr = 0; 

pthread_make_periodic_np(pthread_sel f ( ) ,gethrtime( ) , 400000000) ; 
while(l) 
{ 
pthread_wait_np( ) ; 
(*shm_ptr)++; 
} 

return 0; 
} 

Cote utilisateur, 1' application se contente d'afficher le contenu du segment partage. II est 
interessant de noter que les fonctions de manipulation de mbuff sont les memes cote 
noyau et cote utilisateur. 

#include <stdio.h> 
#include <errno.h> 
#include <mbuff.h> 

#define SHRMEM_NAME "mbufftest" 
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int main(void) 
{ 

int i ; 

volatile int *shm_ptr; 

printfC'NOW MBUFF ALLOCATE. .. \n") ; 

if( (shm_ptr = (volatile int*) mbuff_al loc(SHRMEM_NAME,sizeof (int) ) ) 
{ 

fprintf(stderr,"MBUFF_ALLOC FAILED\n"); 

exit(-l); 
} 

printfC'ALLOC 0K\n"); 

for(i = 0;i < 10;i++) 
{ 

sleep(l) ; 

printfC'SHR MEM IS %d\n" ,*shm_ptr) ; 



mbuff_free(SHRMEM_NAME,(void*)shm_ptr); 
return 0; 



NULL) 



Mesure des temps de latence 

Nous avons effectue un test my_amlat a 2048 Hz pendant 5 minutes sur un systeme non 
charge, puis charge. Nous remarquons que les temps ne depassent pas les 10 us (1 seul point 
a l'exterieur), et ce presque independamment de la charge. Le comportement de RTLinux en 
mode noyau est done peu influence par la charge du systeme (voir figure 9-4, page suivante). 



Utilisation de RTAI 

RTAI (http://www.rtai.org) est un projet GPL issu d'une branche de RTLinux. Le projet est 
maintenu par l'ecole polytechnique de Milan (Politecnico di Milano) en Italie. Les fonc- 
tionnalites et 1' API de RTAI ont de fortes similitudes mais on ne peut pas affirmer qu'il y 
ait une compatibilite totale de RTAI avec 1' API de RTLinux. Le fichier en-tete de compa- 
tibility rt_compat . h (livre avec les sources de RTAI) permet cependant de parvenir a une 
compatibilite partielle pour des applications simples. RTAI partage avec RTLinux la 
compatibilite Posix, 1' utilisation de FIFO de communication ainsi que la memoire parta- 
gee. RTAI inclut en plus le concept LXRT (LinuX Real Time) qui permet d'utiliser des 
applications temps reel dans l'espace utilisateur, ce qui n'est pas le cas de RTLinux. 

Contrairement a RTLinux, il n'existe pas de version commerciale de RTAI et de ce fait 
son approche est moins « industrielle » que celle de RTLinux. Le projet lui-meme inclut 
beaucoup plus de composants que RTLinux, dans 1' esprit plus bazaar typique de certains 
projets Open Source. 



Mises en ceuvre particulieres 

Troisieme partie 



le + 06 



100000 



S! 1000 



100 



10 



0. 1 



charge 
non charge 



0. 1 

Figure 9-4 

Test de latence RTLinux. 
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Les dernieres versions de RTAI (3.1 et Fusion) ont cependant conduit a assainir la 
structure de la distribution. De meme, ces dernieres versions ne sont plus basees sur la 
RTHAL (pour Real Time Hardware Abstraction Layer) qui posait un probleme vis-a-vis 
du brevet logiciel depose par les createurs de RTLinux. RTAI utilise aujourd'hui une cou- 
che basse nominee ADEOS (pour Adaptative Domain Environment for Operating Sys- 
tems). Des informations sur ADEOS sont disponibles a l'adresse http://home.gna.org/ 
adeos. 

RTAI est desormais libere de cette menace de brevet. De plus, sachant que RTLinux est 
devenu un produit quasiment proprietaire (la version GPL n'evoluant plus), RTAI est 
aujourd'hui le choix de predilection pour les utilisateurs de temps reel dur sous Linux. 

Dans la suite du chapitre nous detaillerons l'installation de RTAI-24.1.8 mais egalement 
l'installation de RTAI-3.1 qui constitue actuellement la derniere version stable qui plus 
est utilisable sur les noyaux 2.4 et 2.6. 
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Installation de RTAI-24.1.X 

La distribution RTAI peut etre telechargee depuis le site http://www.aero.polimi.it/RTAI. 
Nous avons utilise la version 24.1.8. Apres extraction de l'archive rtai-24.1.8.tgz, on 
obtient le repertoire /us r/s re/ rtai -24.1.8. 

Premier point important, le fichier GCC-WARNING indique que RTAI ne peut pas utiliser la 
version gcc-2.96 ou 3.x, ce qui pose un probleme aux utilisateurs de distributions Red Hat 
recentes (7.2 en particulier) car e'est le compilateur installe par defaut. La version de compi- 
lateur conseillee est la 2.95.3 qui est plus ancienne. Apres diverses peregrinations, il 
apparait que le plus simple (sur RH 7.2) est de telecharger les sources du compilateur requis 
sur le site ftp://ftp/gnu/org/gnu/gcc et d'installer ce dernier sur un repertoire different de la 
version installee par le systeme comme /usr/local. L'acces au nouveau compilateur se 
fera simplement en placant /usr/local /bin avant /usr/bin dans la variable PATH locale. 

# gec --version 
2.96 

# export PATH=/usr/local/bin:$PATH 

# gec --version 
2.95.3 

La compilation de gec est relativement simple. Apres extraction de l'archive, il suffit de 
se positionner dans le repertoire des sources et d'executer : 

I ./configure 
make 
make install 

Tout comme RTLinux, RTAI est constitue de patches du noyau Linux associes a un 
noyau temps reel sous forme de modules. La version actuelle de RTAI est prevue pour 
fonctionner avec les noyaux 2.2.17, 2.4.16 ou bien 2.4.17. Apres extraction du noyau 
choisi (2.4.17) et installation sur /usr/src/linux-2.4.17_rtai, on peut appliquer le 
patch RTAI en executant : 

Icd /usr/src/1 inux-2.4.17_rtai 
patch -pi < /usr/src/rtai-24.1.8/patches/patch-2.4.17-rthal5g 

Attention 

Tout comme RTLinux, RTAI est prevu pour utiliser la version ofticielle du noyau Linux et non les versions modi- 
fies distributes par les editeurs. 

On doit ensuite configurer le noyau Linux avec make xconf i g en prenant soin de valider 
l'option CONFIG_RTHAL dans le menu Processor type and features. 
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Real-Time Hardware Abstraction Layer 


Help 



Figure 9-5 

Validation du support RTAI. 
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De meme, il ne faut pas valider l'option Set version information on all module symbols 
dans le menu Loadable module support. 

Figure 9-6 

Configuration du support 
des modules. 
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La compilation se fait ensuite par l'enchainement classique : 

make dep 

make clean 

make bzlmage 

make modules 

et 1' installation par : 

I make modules_instal 1 
cp arch/i'386/boot/bzlmage /boot/bzImage-2.4.17_rtai 

De la meme maniere que pour RTLinux, on doit definir une nouvelle entree dans le 
fichier /etc/1 ilo.conf, puis valider par un appel a /sbin/lilo. 

i mage=/ boot /bzlmage- 2. 4. 17_rtai 
1 abel=rtai 
read-only 
root=/dev/hda3 

Apres redemarrage du systeme sur ce nouveau noyau, on doit maintenant configurer la 
partie noyau temps reel. Pour cela, on fait : 

Icd /usr/src/rtai-24.1.8 
make menuconfig 

pour configurer RTAI, ou bien : 

make oldconfig 

si Ton desire conserver la configuration par defaut. On peut aussi lancer le script conf i - 
gure qui lance ensuite la commande make conf ig. 

On effectue ensuite la compilation et 1' installation en executant : 

make modules 

make 

make install 

make dev 

On peut maintenant effectuer le test que propose un exemple livre avec la distribution : 

Iii cd exampl es 
# ./run 
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ce qui lance l'application qui s'affiche dans /var/1 og/messages et les traces du noyau. 

# dmesg 
***** RTAI NEWLY MOUNTED (MOUNT COUNT 1) ****** 

<>» FP RESULT CHECK 35648996 <«> 

<>RT_HAL time: 6 s, AvrJ: 1, MaxJ: 2 us (35648996,-1043,0)0 3001 
<>RT_HAL time: 9 s, AvrJ: 0, MaxJ: 2 us (35648996,-1043,0)0 6002 
ORTJAL time: 12 s, AvrJ: 1, MaxJ: 2 us (35648996,-1043,0)0 9002 
ORTJHAL time: 15 s, AvrJ: 0, MaxJ: 2 us (35648996,-1043,0)0 12003 

On peut stopper l'application avec ./rem. 

# ./rem 
already root 
+sh -c "rmmod -r ex_timer" 

# dmesg 

***** RTAI UNMOUNTED (MOUNT COUNT 1) ****** 

Mesure des temps de latence 

Nous effectuons le meme test qu'avec RTLinux (systeme non charge puis charge). 



j; less 




charge 
non charge 



1 19 

microseconds 



Figure 9-7 

Test de latence RTAI. 
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Installation de RTAI-3.1 

On peut telecharger la distribution a partir de l'adresse http://www.rtai.org en suivant le 
lien Download puis Stable. Contrairement a la version precedente, RTAI-3.1 supporte le 
noyau 2.6 et il est possible de compiler la distribution avec les dernieres versions de gcc 
(3.x), ce qui n'etait pas possible avec les versions 24.1.x. 

Le fichier README.INSTALL donne les indications necessaires a 1' installation de la 
distribution soit : 

1 . Selectionner un noyau Linux compatible avec RTAI et appliquer le patch correspondant. 
La liste des patches est disponible sur le repertoire rtai -core/arch/i386/patches. 

2. Valider le support ADEOS dans le noyau via le menu General setup/Adeos support. En 
general, le support ADEOS sera configure en module. 

3. Compiler ce noyau, l'installer et verifier le bon fonctionnement du systeme. 

4. Executer le script configure du repertoire des sources RTAI-3.1. A la fin de son 
execution, le script doit demarrer une interface graphique permettant de selectionner 
les options de compilation. Dans un premier temps, le mieux est d'utiliser les options 
par defaut. 

5. Compiler puis installer la distribution par mike puis make install. La distribution 
sera installee par defaut sur /us r/ real time. 

Lorsque la distribution est correctement installee, on peut tester les programmes de 
demonstration disponibles dans le repertoire /usr/realtime/testsuite. Le repertoire 
kern correspond aux exemples executes dans l'espace noyau, le repertoire user corres- 
pond aux exemples executes dans l'espace utilisateur (LXRT). 

On peut effectuer un test de latence en mode noyau par la sequence suivante. Nous char- 
geons le systeme en executant en me me temps un petit script d'ecriture de fichier. 

# cd /usr/realtime/testsuite/kern/1 atency 

# ./run 



* Type A C to stop this application. 
* 



## RTAI latency calibration tool 

# period = 100000 (ns) 

# avrgtime = 1 (s) 

# check overall worst case 

# do not use the FPU 

# start the timer 

# timerjnode is oneshot 



2005/04/10 19:39:58 min: 



-2171 



15201 



average: 



1661 
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2005/04/10 
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59 
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max: 
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123 


2005/04/10 


19 


40 


01 


min: 


-3995 


max: 


15543 


average: 


53 


2005/04/10 


19 


40 


02 


min: 


-3995 


max: 


15543 


average: 


99 


2005/04/10 


19 


40 


03 


min: 


-3995 


max: 


20759 


average: 
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Nous constatons que la latence maximale est d'environ 20 us. 

Pour le programme de mesure de latence en mode utilisateur, nous obtenons le resultat 
suivant : 

# cd /usr/real time/testsuite/kern/1 atency 

# ./run 
* 



* Type A C to stop this application. 



## RTAI latency calibration tool 
§ period = 100000 (ns) 

# average time = 1 (s) 

# check overall worst case 

# use the FPU 

# start the timer 

# timerjnode is oneshot 



*** 


min: 


-6063, 


max: 


17946 average: 


1123 


*** 


min: 


-14487. 


max: 


17946 


average: 


3412 


*** 


min: 


-14487. 


max: 


21381 


average: 


1456 


*** 


min: 


-14487. 


max: 


21381 


average: 


1127 


*** 


min: 


-14487. 


max: 


21381 


average: 


1108 


*** 


min: 


-14487. 


max: 


21381 


average: 


1098 


*** 


min: 


-14487. 


max: 


21381 


average: 


1053 


*** 


min: 


-14487. 


max: 


31546 


average: 


3985 


*** 


min: 


-14487. 


max: 


31546 


average: 


1017 


*** 


min: 


-14487. 


max: 


31546 


average: 


1142 



<Hit [RETURN] to stop> *** 

<Hit [RETURN] to stop> 

<Hit [RETURN] to stop> 

<Hit [RETURN] to stop> 

<Hit [RETURN] to stop> 

<Hit [RETURN] to stop> 

<Hit [RETURN] to stop> 

<Hit [RETURN] to stop> 

<Hit [RETURN] to stop> 

<Hit [RETURN] to stop> 



*** 
*** 



La latence est plus importante (environ 30 us soit 10 us de plus) mais le programme de 
test est execute dans l'espace utilisateur, ce qui a d'enormes avantages. 

• Le developpement et la mise au point des programmes en mode utilisateur sont beau- 
coup plus simples. 

• Dans l'espace utilisateur, les problemes lies a la GPL sont moins frequents. 
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Remarque 

Pour le dernier point concernant la GPL, rappelons que Linus Torvalds, createur du noyau Linux considere que 
tout fichier contenant une inclusion (un #include en C) d'un fichier du noyau doit etre diffuse sous GPL. On peut 
lire sur http://seclists.Org/lists/linux-kernel/2003/Dec/1 042.html \a phrase 

BUT YOU CAN NOT USE THE KERNEL HEADER FILES TO CREATE NON-GPL'D BINARIES 
II est done preferable de programmer les taches temps reel dans I'espace utilisateur ! 



Utilisation des patches du noyau 

Les patches du noyau constituent une solution intermediaire entre un noyau standard uti- 
lisant un ordonnanceur a temps partage et un veritable noyau temps reel. Ces patches 
sont legers et dependent de la version du noyau utilise. On peut les appliquer simplement 
en utilisant une ligne de commande du type : 

Icd /usr/src/1 inux-2.4.mon_noyau 
patch -pi < nom_du_fichier_patch 

lis sont associes a la validation d'une option de preemption au niveau de la configuration 
du noyau intervenant avec make xconf i g. L'utilisation d'un noyau modifie de la sorte ne 
transforme pas Linux en systeme temps reel mais permet d'ameliorer les temps de 
latence dans les limites d'une utilisation acceptable pour une application donnee, et ce en 
conservant une interface de programmation classique en mode utilisateur. 

Le patch preempt-kernel-rml 

Ce patch est maintenu par Robert M. Love (rml@tech9.nef) en collaboration avec la 
societe MontaVista (http://www.mvista.com). Les patches, ainsi que differents outils, 
fichiers de documentation et resultats, sont disponibles sur http://www.tech9.net/rml/linux. 

Pour le noyau 2.4, il faut valider l'option Preemptible Kernel du menu Processor type 
and features de la configuration du noyau. Une fonctionnalite similaire est desormais 
integree au noyau 2.6 au niveau du menu Processor type and features/Preemptible kernel. 

Dans le cas de l'utilisation de la commande real feel, on obtient le graphique suivant, 
qui est a comparer avec la figure 9-1 correspondant a un noyau standard. Une tres grande 
majorite des valeurs reste inferieure alms avec un maximum a 45 ms au lieu des plus de 
230 ms precedemment constates. 

maximum latency: 45.2ms 
Mean: 0.0528876799956937ms 
Standard Deviation: 0.0461523751362407 
97.95326% of samples < 0.1ms 
99.557221 of samples < 0.2ms 
99.97026% of samples < 0.5ms 
99.98960% of samples < 0.7ms 
99.99650% of samples < 1ms 
99.99954% of samples < 5ms 
99.99982% of samples < 10ms 
100.00000% of samples < 45.3ms 
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Figure 9-8 

Test realfeel sur un noyau avec patch preempt-kernel. 



Le patch low-latency 

Initialement developpe par Ingo Molnar, ce patch est dorenavant maintenu par Andrew 
Morton (akpm@zip.com.au). II est disponible pour le noyau 2.4 sur le meme site que real- 
feel, soit http://www.zip.com.au/~akpm/linux/schedlat.html. 

Une fonctionnamlite similaire est desormais integree au noyau 2.6 au niveau du menu 
Processor type and features/Preemptive kernel. 

Apres application du patch, il est necessaire de valider le support Low latency scheduling 
dans le menu Processor type and features. L' option Control latency with sysctl permet 
de valider ou non la fonction de maniere dynamique en utilisant l'entree /proc/sys/ 
kernel /I ow_l atency. 

Teste avec le programme realfeel, le noyau 2.4.17 utilise donne de tres bons resultats 
sur cinq millions d' interruptions, la valeur maximale ne depassant pas 1,4 ms. 

I maximum latency: 1.3ms 
Mean: 0.0542797399957571ms 
Standard Deviation: 0.025220506601371 
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Figure 9-9 

Test realfeel sur noyau avec patch low-latency. 



96.66250% of samples < 0.1ms 
99.21158% of samples < 0.2ms 
99.99592% of samples < 0.5ms 
99.99984% of samples < 0.7ms 
99.99992% of samples < 1ms 
100.00000% of samples < 1.4m 

Combinaison de patch 

II est possible de combiner les patches preempt-kernel et low-latency car ils ne touchent 
pas les meme portions de code dans le noyau Linux. Le fait de combiner l'approche du 
premier, qui tend a ajouter des points de preemptions systematiques, avec celle du second, 
qui tend a reduire les longs intervalles de temps sans appel a l'ordonnanceur, semble don- 
ner de bons resultats. Apres application du patch preempt-kernel puis low-latency, on 
obtient le graphe suivant sur cinq millions d' interruptions. On note surtout que la combi- 
naison des deux patches permet d'augmenter le nombre de valeurs inferieures a 100 us. 
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Figure 9-10 

Test realfeel sur la combinaison des deux patches. 



minimum latency: < 0.1ms 
maximum latency: 1.2ms 
Mean: 0.0520061799956548ms 
Median: 0.05ms 

Mode: 0.05ms (occurred 4915634 times) 
Variance: 0.000282321298762259 
Standard Deviation: 0.0168024194318038 
98.31268% of samples < 0.1ms 
99.76028% of samples < 0.2ms 
99.99648% of samples < 0.5ms 
99.99978% of samples < 0.7ms 
99.99992% of samples < 1ms 
100.00000% of samples < 1.3ms 



Au moment de la redaction de ces lignes, il semblerait qu'un patch unique combinant les 
deux fonctionnalites soit envisage. 
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Le patch rtsched 

Le projet rtsched (http://rtsched.sourceforge.net) vise (visait) a modifier l'ordonnanceur 
Linux de maniere a separer les taches temps reel des autres taches. De ce fait, le type 
SCHED_OTHER n'est pas traite de la meme maniere que les types SCHED^RR et SCHED_FI FO. 
Le traitement des quantums de temps est egalement optimise. La validation s'effectue au 
niveau de la configuration du noyau dans le menu Processor type and features, ou il faut 
valider 1' option Real Time Scheduler et definir la valeur maximale de priorite correspon- 
dant a une tache temps reel. Les taches de priorite 1 jusqu'a cette valeur seront conside- 
rees par le systeme comme des taches temps reel. Le patch est disponible jusqu'a la 
version 2.4.16 du noyau Linux et il semble que le projet (egalement sponsorise par Mon- 
ta Vista) n'evolue plus et que les approches precedentes aient pris le pas sur rtsched. 

En resume 

Le noyau Linux standard utilise un ordonnancement a temps partage et une forte charge 
du systeme peut induire des temps de latence importants et surtout imprevisibles. 

Le comportement peut etre ameliore par des patches comme kernel-preempt ou low- 
latency qui reduisent ces temps de latence mais ne transforment pas Linux en vrai sys- 
teme temps reel. II est done prudent de reserver cette technique a des applications temps 
reel souples. Lavantage principal en est l'API de programmation qui n'est pas modifiee 
par rapport a un noyau Linux standard. 

Les produits RTLinux et RTAI utilisent une technique d'ajout d'un veritable noyau temps 
reel en parallele au noyau Linux, ce dernier etant considere comme une tache de plus fai- 
ble priorite du noyau temps reel. Cette technologie permet de mettre en place des syste- 
mes temps reel a contraintes dures. Les taches temps reel doivent cependant etre 
developpees avec une API speciale dans l'espace noyau et non dans l'espace utilisateur. 

Une version GPL de RTLinux peut etre utilisee, mais seulement pour des applications 
GPL. La nouvelle version GPL de RTLinux n'est plus tres a jour par rapport a la version 
proprietaire. II est done preferable d'utiliser RTAI qui est un veritable projet libre, offrant 
des performances similaires. II permet de programmer des taches temps reel dans l'espace 
utilisateur, ce qui evite les problemes de conformite avec la GPL. 
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Presentation de uClinux 

Le projet uClinux (a prononcer « you see LINUX ») est un portage du noyau Linux pour 
les processeurs depourvus de MMU {Memory Management Unit, voir chapitre 3). Le 
projet a demarre en 1998 par le portage d'un noyau 2.0 sur un processeur Motorola 
M68328 mais le produit existe maintenant en version 2.4 et 2.6. 

La page d'accueil du projet est situee a l'adresse http://www.uclinug.org. Le nombre 
d' architectures supportees a depuis explose et uClinux se presente aujourd'hui comme 
un concurrent tres serieux des systemes d' exploitation embarques pour micro-con troleurs. 
La liste des processeurs supportes par uClinux est disponible sur http://www.uclinux.org/ 
ports. De meme, la distribution des sources permet a des constructeurs de solutions mate- 
rielles de fournir des portages de uClinux pour leurs produits. C'est par exemple le cas du 
processeur NIOS developpe par la societe Altera (http://www.altera.com), pour lequel cette 
derniere fournit un environnement de developpement complet base sur uClinux et la 
chaine de compilation GNU. La description de ce produit est disponible a l'adresse http:// 
www. altera. com/products/devkits/altera/kit-dev_linux. html. 

Le gros avantage de uClinux par rapport a ses concurrents est la compatibilite de l'API 
de programmation avec les systemes Linux standards. II dispose egalement de toutes les 
fonctionnalites reseau TCP/IP disponibles sur le noyau Linux, ce qui est egalement un 
tres gros avantage dans le cas du developpement d'un produit communicant. Le systeme 
uClinux est egalement tres raisonnable au niveau de l'empreinte memoire avec une taille 
de noyau inferieure a 512 Ko, la liste des commandes utilisateur etant inferieure a 
900 Ko. Les micro-controleurs etant souvent utilises dans des environnements temps 
reel, il existe egalement un portage de RTLinux pour le noyau uClinux 2.0 a l'adresse 
http://www.uclinux.org/pub/uCsimm/Rt-port. 
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L'API etant compatible avec celle de Linux, il est possible d'effectuer des portages 
d' applications vers l'environnement uClinux. De meme, de nombreux outils et program- 
mes adaptes a l'environnement reduit comme Boa (serveur http embarque) sont disponi- 
bles pour uClinux. 

L' absence de MMU impose cependant quelques contraintes par rapport a un environne- 
ment Linux classique : 

• La memoire virtuelle n'existe pas. Le noyau et les programmes applicatifs partagent le 
meme espace d'adressage, ce qui implique qu'une application mal ecrite peut mettre 
en peril le fonctionnement global du systeme. 

• Lappel systeme fork n'est pas supporte. II est remplace par une implementation de 
l'appel systeme vf ork BSD (le processus parent est suspendu jusqu'a ce que le proces- 
sus fils appelle exec ou exi t). 

• L'appel systeme exec ne peut pas charger une image binaire superieure a 256 Ko. 

• La taille de la pile est fixe pour chaque processus. 



Quelques kits materiels disponibles 



La mise en oeuvre de uClinux est un peu plus complexe que celle d'un Linux classique 
car elle necessite un environnement materiel particulier alors que Linux peut etre teste 
sur une plate-forme x86 grand public. Pour utiliser uClinux, il est necessaire de faire 
l'acquisition d'un kit devaluation (on peut aussi le fabriquer soi-meme). Les kits d'eva- 
luation uCsimm, Geek Kit, uCdimm et ARM7TDMI sont disponibles en ligne sur http:// 
www. uclinux. com. 



Le kit uCsimm 



Le module uCsimm est concu specialement pour le systeme uClinux. II est constitue 
d'un module SIMM standard 30 broches equipe d'un micro-controleur DragonBall 
M68EZ328 a 16 MHz, de 2 Mo de memoire flash de 8 Mo de memoire vive. Le module 
dispose egalement des fonctions suivantes : 

• interface Ethernet lOBaseT, 

• un port serie RS-232, 

• 21 entrees/sorties multi usages, 

• piloted'afficheurLCDouQVGA, 

• bus I2C ou SPI3 a 1 Mbit/s. 

Le systeme est alimente en 3,3 V. II peut facilement etre utilise avec un connecteur SIMM 
et un cable serie. La figure ci-apres donne l'encombrement du module. 
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Figure 10-1 

Module uCsimm. 



Le kit uCgardener contient le module uCsimm, le CD-Rom uClinux et le kit de montage 
du support SIMM. La memoire flash du module contient un moniteur permettant de tele- 
charger en RAM 1' image du systeme uClinux via le port serie et de 1' installer dans la 
memoire flash. Ce kit existe en version economique, a monter soi-meme, sous la refe- 
rence Geek Kit. 



Le kit uCdimm 



Le kit uCdimm est une version plus performante du kit uCsimm. II se presente sous la 
forme d'un module DIMM 144 broches de 1,7 sur 2,7 pouces. Ce dernier est equipe d'un 
micro-controleur DragonBall VZ (68VZ328) a 33 MHz, de 2 Mo de memoire flash et 
8 Mo de memoire vive DRAM. Le module integre en outre : 

• un controleur de DRAM, 

• deux ports serie, deux interfaces SPI, 

• un controleur LCD (resolution j usqu ' a 640 x 5 1 2) , 

• jusqu'a 22 E/S paralleles, 

• une horloge temps reel - calendrier, 

• une interface Ethernet lOBaseT. 

Le reste du contenu du kit est identique a celui du kit uCsimm. 



Le kit ARM7TDMI 



Base sur un processeur ARM (ATMEL AT91), le kit ARM7TDMI offre plus de puissance 
que les modules precedents. Le kit est compose de la carte devaluation ATMEL EB40- 
LS et d'une carte fille Lineo uCnet pour la connexion Ethernet et 1' extension de memoire 
flash. Les caracteristiques du kit sont les suivantes : 

• processeur ARM7TDMI avec 128 Ko de SRAM interne, 

• 2 Mo de memoire statique SRAM, 

• 128 Ko de memoire flash, plus 2 Mo sur la carte ucent, 
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• deux ports serie, 

• portJTAG, 

• une interface Ethernet lOBaseT IEEE 802.3. 

Le projet Open Hardware 

Open Hardware (http://www.openhardware.net) a une approche similaire au developpe- 
ment Open Source mais appliquee au materiel. Tous les schemas, documentations et 
nomenclatures sont telechargeables depuis le site Open Hardware. Le projet propose 
diverses cartes mere telle celle presentee sur la figure ci-apres. 




Figure 10-2 

Exemple de carte Open Hardware. 



Cette carte mere dispose de quatre emplacements SIMM 72 broches dont deux sont 
libres d' utilisation, plus un connecteur RJ45 pour l'acces Ethernet IEEE 802.3 lOBaseT, 
une interface pour ecran LCD et une interface pour ecran tactile. Elle est equipee en plus : 

d'un processeur Motorola DragonBall EZ, 

de 8 Mo de DRAM, 

de 2, 4 ou 8 Mo de memoire flash, 

d'une horloge temps reel avec sauvegarde par pile bouton, 

de 9 E/S paralleles, 

d'un module SIMM 72 broches comportant le controleur Ethernet. 
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La carte devaluation ColdFire Motorola M5407C3 

La plate -forme materielle utilisee dans la suite de ce chapitre est la carte d' evaluation 
Motorola M5407C3 a base de processeur ColdFire. Les cartes d' evaluation proposees 
par les fabricants de composants sont d'un cout peu eleve et represented un moyen 
rapide de tester des fonctionnalites bien precises comme des convertisseurs analogiques/ 
numeriques, des amplificateurs operationnels ou des processeurs. 

La distribution uClinux pour ColdFire supporte un ensemble de cartes devaluation du 
commerce comme : 

• les cartes Arnewsh SBC5206 et SBC5307, 

• les cartes Motorola M5206eLITE, M5206C3, M5307C3, M5272C3, 

• les cartes Lineo eLIA 5307, NETtel et SecureEdge, 

• la carte Netburner CFV2-40. 

La carte devaluation M5407C3 utilise le processeur ColdFire MCF5407 qui est le suc- 
cesseur du celebre processeur Motorola 68000 dont la production s'est arretee avec le 
microprocesseur 68060 il y a quelques annees. II reprend le jeu d' instructions du micro- 
processeur 68020 dans lequel on a supprime quelques instructions et modes d'adressage 
peu utilises. Selon les versions de processeur ColdFire, Motorola a ajoute des instruc- 
tions de type MAC (Multiply and AC Cumulate) que Ton retrouve dans les processeurs de 
traitement du signal (Digital Signal Processing ou DSP). Une vue de la carte M5407C3 
est presentee sur la figure ci-apres. 




Figure 10-3 

Carte M5407C3. 
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La carte d'evaluation M5407C3 possede : 

• un processeur MCF5407 a 150 MHz, 

• 32 Mo de memoire SDRAM, 

• 2 Mo de memoire flash dont 0,3 Mo occupe par le moniteur de la carte, 

• 2 ports serie, 

• une liaison Ethernet IEEE 802.3 lOBaseT, 

• un port de debogage BDM (Background Debugger Module), 

• un emplacement PCI. 



Mise en ceuvre de uClinux 

Nous utilisons pour la mise en oeuvre de uClinux le processeur ColdFire qui est installe 
sur la carte d'evaluation Motorola M5407C3. La demarche a suivre serait bien stir simi- 
laire pour des versions de uClinux adaptees a d'autres processeurs. 

La distribution uClinux pour ColdFire est basee initialement sur un noyau Linux 2.0.38 
mais propose aussi une version utilisant le noyau 2.4.10. Lensemble est stable et offre 
une large palette de services comme : 

• des clients NFS et SMB, 

• un client DHCP, 

• la fonction dTP masquerading, 

• des serveurs HTTP reduits (comme Boa et thttpd). 

La mise en oeuvre de uClinux/ColdFire pour la generation de 1' image a telecharger dans 
la carte d'evaluation ressemble fort a une generation d'un noyau Linux. II faut tout 
d'abord recuperer les archives sur le site uClinux/ColdFire, soit : 

la chaine de compilation croisee ColdFire (fichier m68k-el f-tool s-xxxxxxxx.tar.gz), 

la distribution de uClinux/ColdFire (fichier uclinux-dist-xxxxxxxx.tar.gz). 

On doit tout d'abord installer sur le PC Linux hote la chaine de compilation croisee Cold- 
Fire (cross development). Pour ce faire, en tant que super-utilisateur, on execute : 

I# cd / 
# tar xvfz m68k-elf-tools-20010716.tar.gz 
# exit 

II faut ensuite installer la distribution uClinux/ColdFire dans son repertoire de travail en 
tant que simple utilisateur. 

1$ tar xvfz uClinux-dist-20011112.tar.gz 
$ cd uClinux-dist/ 
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On retrouve ensuite l'enchainement classique de compilation d'un noyau sous Linux, 
soit en premier lieu la partie configuration. 

j $ make xconfig 

Le menu decrit ci-apres permet de configurer le noyau uClinux. 



Target Platform Selection | 




Choose a Vendor/Product combination. 


A 


Motorola/MS407 


Vendor/Product 


Help 


uGinux-Z.O.x 


Kernel Version 


Help 




Library is uC-libc (old) 


v y 


V " 


♦ n 


Default all settings (lose changes) 


Help 


♦ y 


v ~ 


v n 


Customize Kernel Settings 


Help 


♦ y 


V " 


v n 


Customize Vendor/User Settings 


Help 


v y 


v ~ 


♦ n 


Update Default Vendor Settings 


Help 






Main Menu 





Figure 10-4 

Configuration du noyau pClinux. 

De meme, le menu decrit ci-apres permet de choisir et configurer les applications a utili- 
ser. N'oublions pas que, dans uClinux, les applications et le noyau partagent le meme 
espace d'adressage. 
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Figure 10-5 

Configuration et choix des applications. 
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Apres sauvegarde de la configuration, on effectue ensuite la compilation comme pour un 
noyau Linux. Notez que le compilateur utilise n'est pas la version native de la station 
Linux mais la version croisee pour le processeur ColdFire. 

1$ make dep 
$ make 

Si la compilation se deroule sans erreur, l'image binaire i mage . bi n du systeme uClinux/ 
ColdFire est placee dans le repertoire /tf tpboot afin d'etre telechargee dans la memoire 
vive de la carte devaluation via le reseau Ethernet avec le protocole TFTP (Trivial FTP). 

Pour ce faire, on se connecte a la carte par le port serie en utilisant une application 
d'emulation de terminal comme kermit ou mini com, puis on utilise la commande dn du 
moniteur afin de demarrer le telechargement. 

$ kermit 

Connecting to /dev/ttySl, speed 19200. 

The escape character is Ctrl -\ (ASCII 28, FS) 

Type the escape character followed by C to get back, 

or followed by ? to see other options. 



Hard Reset 
DRAM Size: 32M 

Copyright 1995-1999 Motorola, Inc. All Rights Reserved. 

ColdFire MCF5407 EVS Firmware vZe.la.la (Build 1 on Jul 27 2000 16:35:59) 

Enter 'help' for help. 

dBUG> dn image.bin 

Eth Mac Addr is 00 : CF : 54: 07 : C3 : 01 

Downloading Image 'image.bin' from 147.200.10.209 



1269540 bytes read via TFTP 

Lorsque le telechargement est termine, on peut demarrer le noyau uClinux/ColdFire. 
Pour cela, on execute : 

dBUG> go 20000 
uClinux/C0LDFIRE(m5407) 

COLDFIRE port done by Greg Lingerer, gerg@lineo.com 

Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne 
Calibrating delay loop., ok - 149.50 BogoMIPS 

Memory available: 30892k/32768k RAM, Ok/Ok ROM (359k kernel code, 140k data) 
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I Execution Finished, Exiting 
Sash command shell (version 1.1.1) 
l> 
On remarquera sur les traces precedentes que la taille du noyau est inferieure a 500 Ko. 
Nous disposons maintenant d'un systeme Linux embarque operationnel sur lequel on 
peut executer des applications, par exemple le serveur web embarque Boa : 

I/> boa& 
[20] 
/> 



Exemple d'application |iClinux 

L' exemple d'application simple presente ici consiste en la mise en place d'une fonction 
de pilotage a distance d'un equipement electronique (en l'occurrence la carte d'evalua- 
tion) a travers un navigateur Internet en utilisant une technologie CGI {Common Gateway 
Interface). Pour cela, on utilise bien sur le serveur Boa qui supporte 1' interface CGI. 

Nous rappelons ici que l'interface CGI est un moyen simple d'executer une application 
quelconque depuis une interface graphique HTML. Le principe met en oeuvre la balise 
FORM du langage HTML de la maniere suivante : 

<B0DY> 

<F0RM ACTION="led_control .cgi"> 

LED 

<INPUT TYPE=radio NAME="C0NTR0LE" VALUE="on"> allumee 

<INPUT TYPE=radio NAME="C0NTR0LE" VALUE="off"> eteinte 

<P> 

<INPUT TYPE=submit NAME=" VALIDE" VALUE="Val ider"> 

</F0RM> 

</B0DY> 

Le fichier led_contro1 .cgi constitue le programme CGI et il peut etre ecrit dans 
n'importe quel langage a partir du moment ou il respecte les specifications de l'interface 
CGI. Pour tester notre environnement sur la station de travail, on peut pour l'instant uti- 
liser le script shell suivant comme programme CGI. 

#!/bin/sh 

echo Content-Type: text/html 

echo 

echo "<BODY>QUERY_STRING= [$QUERY_STRING]</BODY>" 

Les deux premieres commandes echo constituent l'en-tete standard que doit envoyer le 
programme CGI au navigateur, le reste de la page est affiche dynamiquement grace a 
la troisieme commande echo. Par defaut, le programme CGI regoit les parametres de la 
page dans la variable d' environnement QUERY_STRING sous la forme d'une suite de 
chaines de caracteres separees par le caractere &. 



I 



variablel=valeurl&variable2=valeur2&. . .&variableN=valeurN 
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Lorsque Ton visualise cette page avec un navigateur, on obtient l'ecran suivant 

LED v sdlumee " eteinte 




VsJidier 



Figure 10-6 

Test de la forme HTML. 

Si Ton clique sur l'un ou l'autre des boutons (allumer ou eteindre la LED) puis que Ton 
clique sur Val ider, on obtient l'affichage suivant dans la fenetre du navigateur : 

QUERY_STRING= [C0NTR0LE=off&VALIDE=Val ider] 

Dans le veritable programme CGI, il est done simple d'extraire le parametre de controle 
et de l'utiliser arm d'envoyer la bonne commande bas niveau pour eteindre ou allumer la 
LED. 

#i include <stdio.h> 
^include <stdlib.h> 

main () 
{ 

char *param, control ; 

extern char *getenvC); 

short *PADAT = (short*)0xl0000244; 

printf ("Content-Type: text/html \n\n" ) ; 

if ( ! (param = getenv ("QUERY_STRING" ) ) ) { 

printf ("<B0DYXHl>Pas de parametre!</HlX/BODY>") j 

exit (1); 
} 

/* Recherche de la valeur */ 
while (*param && *param++ != '=') 



control = *param - '0' ; 

switch (control ) { 
case 0: 

/* Eteint */ 

printf ("<B0DYXH1>LED eteinte</HlX/BODY>" ) ; 

*PADAT |= 0x0080; 

break; 
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case 1: 
/* Allume */ 

printf ("<B0DYXH1>LED al lumee</HlX/BODY>") ; 
*PADAT &= 0x007f; 
break; 

default: 

printf ("<BODYXHl>Parametre incorrect!</HlX/BODY>" , param) 
exit (1); 



Dans le cas du systeme uClinux, le programme CGI est done ecrit en C (1 edctl . c) et 
installe sur le repertoire uCl inux-dist/vendors/Generic/cgi. II est ensuite « cross- 
compile », afin de generer le programme CGI (fichier 1 edctl . cgi ) qui sera installe sur le 
repertoire /home/httpd de l'image uClinux. Le serveur Boa doit egalement etre parametre 
afin d'autoriser l'execution de CGI. 



En resume 



uClinux est une version de l'environnement Linux adaptee aux processeurs et micro-con- 
troleurs depourvus de MMU. L utilisation d'un systeme tel que Linux permet de profiter 
des fonctionnalites du systeme Linux standard au niveau reseau et services de type 
HTTP, fonctions qui sont souvent couteuses ou difficiles a mettre en place dans les envi- 
ronnements proprietaires. 

La mise en place d'une solution uClinux necessite cependant un test prealable sur une 
carte d'evaluation, ce qui est un desavantage par rapport a une solution Linux classique 
qui peut etre testee sur un systeme grand public a bas cout. 
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Developpement croise 



Nous avons pour l'instant vu des exemples dans l'environnement Intel x86. Meme si cet 
environnement est tres repandu, il est loin d'etre le plus utilise dans les applications 
industrielles et embarquees. Comme nous 1' avons vu au chapitre 3, d'autres processeurs 
comme 1' ARM ou le PowerPC sont parfois mieux adaptes que 1' architecture x86. 

Cependant, la plupart des developpeurs utiliseront un PC x86 (Linux ou Windows) comme 
poste de travail, il est done necessaire de mettre en place une chaine de developpement 
croisee permettant de produire du code non-x86 sur un PC. Dans ce chapitre, nous allons 
decrire plusieurs solutions Open Source disponibles, utilisables sur Linux x86. Nous 
expliquerons egalement comment mettre en oeuvre certains de ces outils sur plate-forme 
Windows en utilisant l'environnement d'emulation CYGWIN. 

A titre d'exemple, nous mettrons en place et testerons une chaine de developpement pour 
cible Linux ARM. 



Principe de la compilation sous Linux 

La chaine de compilation GNU utilise les composants suivants : 

• le compilateur qui constitue le paquetage gec ; 

• les outils annexes (assembleur, editeur de liens, etc.) qui constituent le paquetage 
binutils ; 

• la GNU-Libc qui constitue le paquetage gl ibc. Ce paquetage contient en general la 
bibliotheque de gestion des threads (LinuxThreads). 

Dans le cas d'un systeme Linux x86, ces paquetages sont installes sur le systeme sous 
forme de paquetages RPM ou DEB dans le cas de la distribution Debian. 
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Dans le cas de la distribution Red Hat, nous aurons par exemple : 

$ rpm -qv gcc 

gcc-3.2.2-5 

$ rpm -qv binutils 

binutils-2. 13. 90. 0.18-9 

$ rpm -qv glibc 

glibc-2.3.2-11.9 

Concemant le paquetage bi nuti 1 s, ce dernier contient des outils utilises pour la generation 
et la manipulation des executables ou des fichiers objets (fichiers .o) intermediaires. On 
notera dans ce paquetage la presence de l'assembleur as ou de l'editeur de liens 1 d : 



$ rpm - 
/usr/bi 
/usr/bi 
/usr/bi 
/usr/bi 
/usr/bi 
/usr/bi 
/usr/bi 
/usr/bi 
/usr/bi 
/usr/bi 
/usr/bi 
/usr/bi 
/usr/bi 



ql binutils 

n/addr21 ine 

n/ar 

n/as 

n/gprof 

n/ld 

n/nm 

n/objcopy 

n/objdump 

n/ranl ib 

n/readel f 

n/size 

n/strings 

n/strip 



Dans le cas de la compilation croisee, ces differents outils, ainsi que le compilateur, seront 
executes dans un environnement x86 (Linux ou Windows) mais le code genere sera d'un 
type different (par exemple ARM). II est done necessaire de compiler le paquetage a par- 
tir des sources en specifiant de nouvelles options de generation. Pour ce faire, le script 
conf i gure inclus dans les paquetages permet de specifier le type d' architecture sur lequel 
s'execute l'outil (option --host) ainsi que le type d' architecture cible (option --target). 

Dans le cas ou les options ne sont pas precisees, le script generera par defaut une configu- 
ration pour un executable natif, a utiliser dans 1' environnement de compilation courant. 
Voici un exemple pour le paquetage bi nuti 1 s : 



$ ./configure 

loading cache ./config. cache 
checking host system type... 
checking target system type., 
checking build system type... 



i 686-pc-l inux-gnu 
. i 686-pc-l inux-gnu 
i 686-pc-l inux-gnu 



Par contre, si Ton precise les options citees precedemment on obtient 

$ ./configure --host=i 686-pc-l inux-gnu --target=arm-l inux 
creating cache ./config. cache 
checking host system type... i 686-pc-l inux-gnu 
checking target system type... arm-unknown-1 inux-gnu 
checking build system type... i 686-pc-l inux-gnu 
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La generation de la chaine de compilation croisee est done realisable a la main mais elle 
est souvent fastidieuse car elle peut necessiter 1' application de patches sur un ou plu- 
sieurs paquetages en fonction des differentes architectures. De ce fait, l'utilisateur non 
averti risque de disposer d'une chaine erronee et il est done conseille d'utiliser des outils 
specialises. 

Dans la suite du chapitre, nous presenterons done l'outil ELDK (Embedded Linux Deve- 
lopment Kit) developpe par DENX Sofware (http://www.denx.de/ELDK.htmf) ainsi que 
l'outil CROSSTOOL developpe par Dan Kegel (http://kegel.com/crosstoof). Nous preci- 
sons que ces deux outils sont totalement libres et diffuses sous licence GPL. II n'y a pas 
non plus de restrictions concernant les projets developpes avec ces outils. 



L'outil ELDK 



ELDK est developpe par Denx Sofware, societe de consulting Linux situee en Allemagne. 
Le fondateur, Wilfried Denk, est un professionnel de talent, contribuant a de nombreux 
projets Open Source dont RTAI (http://www.rtai.org). 

Le produit est disponible sous forme de paquetages RPM binaires ou sources. II est ega- 
lement possible de telecharger l'image ISO du CD-Rom contenant les binaires ou les 
sources. ELDK permet de mettre en place une chaine de compilation utilisable sur un PC 
Linux x86 pour des cibles PowerPC, MIPS ou ARM. Cet outil fournit egalement une dis- 
tribution que Ton peut utiliser comme root-file system au travers d'un montage NFS. 
Cette technique facilite la mise au point car il n'est pas necessaire de mettre a jour syste- 
matiquement la cible. La version de noyau fournie par ELDK est la 2.4.25 amelioree par 
DENX principalement pour la plate-forme PowerPC. 

Linstallation est tres simple. II suffit de telecharger l'image ISO du CD-Rom aupres d'un 
des miroirs du projet, soit : 

ftp.V/mirror. switch, ch/mirror/eldk/eldk/ 

http://mirror.switch.ch/ftp/mirror/eldk/eldk/ 

ftp://sunsite. utk. edu/pub/linux/eldk/ 

http://sunsite. utk. edu/ftp/pub/linux/eldk/ 

ftp:/ /ftp. sunet. se/pub/Linux/distributions/eldk/ 

http://ftp.sunet.se/pub/Linux/distributions/eldk/ 

ftp:/ /ftp. leo. org/pub/eidk/ 

http://archiv.leo.org/pub/comp/os/unix/linux/eldk/ 

La derniere version a ce jour est la 3. 1 . 1 et il faut noter que les images ISO n' existent pas 
forcement pour les anciennes versions comme la 2. 1 .0. A partir de 1' image ISO, il est aise 
de graver le CD-Rom sur un systeme Linux, ou meme sur une machine Windows. On 
peut aussi utiliser l'image ISO grace au loopback device decrit au chapitre 5 et monter le 
fichier en utilisant la commande suivante : 

mount -t iso9660 -o loop mon_image.iso /mnt/cdrom 
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Lorsque l'image (ou le CD-Rom) est montee, on peut installer la distribution en executant 
simplement la commande suivante : 

$ /mnt/cdrom/instal 1 -d /opt/el dk_arm 

Do you really want to install into /opt/eldk_arm di rectory[y/n]?: y 

Creating directories 

Done 

Installing cross RPMs 



Preparing. . . 
l:rpm 

Preparing. . . 

l:rpm-build 
Preparing. . . 

l:binutil s-arm 



[100% 
[100% 
[100% 
[100% 
[100% 
[100% 



Dans le cas du PowerPC, on pourra preciser les architectures a installer (ppc_4xx, ppc_ 
6xx, etc.). Par defaut, la procedure installe toutes les architectures. 

$ /mnt/cdrom/instal 1 -d /opt/el dk_ppc ppc_4xx ppc_6xx 



Remarque 

II n'est pas necessaire d'installer ELDK en tant que super-utilisateur (root). Dans le cas ou ELDK est installe en 
tant que simple utilisateur, il est bien entendu necessaire d'avoir les droits d'ecriture sur le repertoire d'installa- 
tion. Dans le cas de I'utilisation du root-filesystem ELDK par NFS, il sera necessaire d'utiliser le script eldk_ 
makedev pour creer les entrees dans le repertoire /dev de l'image fournie par ELDK. Si ELDK n'est pas installe 
en tant que super-utilisateur, il faudra utiliser le script eldk_fixowner pour configurer correctement l'image NFS 
comme decrit dans la documentation ELDK sur http://www.denx.de/twiki/bin/view/DULG/ELDKMountingTar- 
getComponents ViaNFS. 



Lorsque le paquetage est installe, la chaine de compilation est utilisable si Ton rajoute le 
chemin d'acces aux outils a sa variable d'environnement PATH comme ci-dessous : 

1$ PATH=/opt/eldk_arm/usr/bin:$PATH 
$ export PATH 

A partir de la, on peut utiliser le compilateur et les outils associes : 

$ arm-linux-gcc -v 

Lecture des specifications a partir de /opt/eldk_arm/usr/bin/. ./lib/gcc-1 ib/ 

**arm-l inux/3.3.3/specs 

Configure avec: ../configure --prefix=/usr --mandi r=/usr/share/man --infodir=/usr/ 

**share/info --enable-shared --enable-threads=posix --disable-checking --with-system- 

**zlib --enable- cxa_atexit --with-newl ib --enable-1 anguages=c,c++ --disable-1 ibgcj 

*»--host=i386-redhat-l inux --target=arm-l inux 

Modele de thread: posix 

version gcc 3.3.3 (DENX ELDK 3.1.1 3.3.3-9) 
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On peut compiler le programme de test traditionnel Hello World : 

$ arm-1 inux-gcc -o helloword helloworld.c 

$ file helloworld 

helloworld: ELF 32-bit LSB executable, ARM, version 1 (ARM), for GNU/Linux 2.2.5, 

•dynamically linked (uses shared libs), not stripped 

La derniere commande indique bien que nous sommes en presence d'un executable ARM. 



L'outil CROSSTOOL 

L'outil CROSSTOOL est quelque peu different car il est plus complexe a apprehender 
mais aussi plus souple. Le complexite vient du fait qu'il n'existe pas de distribution 
binaire ni de programme d' installation aussi simple que pour ELDK. C'est d'ailleurs tout 
a fait normal car le but de CROSSTOOL est de fournir a l'utilisateur un ensemble de 
scripts lui permettant de construire sa chaine de compilation meme dans les cas les plus 
complexes alors qu'ELDK est limite a l'hote Linux x86 et aux cibles PowerPC, MIPS et 
ARM. Avec CROSSTOOL, on choisit done l'environnement hote (host), la cible (target), 
les versions des paquetages a utiliser (gec, binutils, etc.) mais aussi les differents patches a 
appliquer aux differents paquetages ou bien le noyau utilise et ses patches associes. CROSS- 
TOOL effectue egalement le telechargement des paquetages necessaires a la generation 
de la chaine definie par l'utilisateur. 

L'outil CROSTOOL est entierement ecrit en langage script shell ce qui lui donne un air 
old style qui n'est pas pour deplaire aux geeks chevronnes. 



Definition recreative 

Le terme geek vient de I'argot des informaticiens anglo-saxons et designe un passionne de technique informati- 
que plus enclin a ('utilisation des obscurs langages de script, esoteriques mais efficaces que des interfaces 
graphiques et autres « cliquodromes ». Le geek a une facheuse tendance a une certaine goujaterie voire un 
certain machisme involontaire qui est plus un effet de bord du a sa passion qu'un veritable choix de comporte- 
ment. Demontrant une fois de plus le sens pratique feminin, certaines compagnes de geeks se sont associees 
en France sous le terme « copines de geek » (http://www.copinedegeek.com). 



Pour utiliser CROSSTOOL, il faut tout d'abord installer l'archive telechargee depuis le 
site de Dan Kegel. Dans notre cas nous allons utiliser la version 0.31, derniere a jour au 
moment de l'ecriture de ces lignes. Une fois la distribution installee, une documentation 
en anglais est disponible dans le fichier doc/crosstool -howto.html. 

La structure du repertoire crosstool -0.31 est tres simple, les fichiers importants etant 
localises directement sur la racine du repertoire : 

• Le fichier ill . sh est le script principal de generation de la chaine. 

• Les fichiers type demo-xxx.sh comme demo -i 686. sh sont des exemples fournis dont 
l'utilisateur peut s'inspirer pour construire sa propre configuration. 
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Les fichiers .dat permettent de definir des variables d'environnement utilisees par les 
scripts. Par exemple, le fichier i 686-cygwi n . dat definit des variables indiquant que la 
cible est CYGWIN. 

$ cat i686-cygwin.dat 
TARGET=i686-pc-cygwin 
TARGET_CFLAGS="-0" 

Les fichiers . conf i g correspondent a des configurations du noyau Linux generees par 
un mike xconfig ou un make config et ce pour les differents processeurs supportes 
(comme i 686. config, m68k. config). Ce principe peut etre etendu a tout autre systeme 
de configuration utilisant un format similaire. Ces fichiers sont utilises par les fichiers 
.dat cites precedemment. 

$ cat i 686 .dat 

KERNELCONFIG='pwdVi 686. config 
TARGET=i686-unknown-l inux-gnu 
TARGET_CFLAGS="-0" 

D'autres sous-repertoires sont presents et nous pouvons citer : 

• Le repertoire downl oad qui accueille les paquetages sources manquants telecharges par 
CROSSTOOL lors de la generation de la chaine. 

• Le repertoire patches qui contient lui-meme des sous-repertoires correspondant aux 
differents paquetages utilisables. Chaque sous-repertoire contient les patches a appli- 
quer en fonction de la configuration definie par l'utilisateur. Nous pouvons donner 
1' exemple du paquetage correspondant agcc-3.3.4 : 

$ Is -w 1 patches/gcc-3.3.4/ 
gcc-3.3.4-arm-bigendian.patch 
gcc-3.3.4-libstdcxx-sh.patch 
gcc-3.3.4-ppc-asm-spec.patch 

La documentation propose en tant qu' introduction de generer une chaine de compilation 
native i686 ce qui n'a pas beaucoup d'interet autre que pedagogique. Pour cela, il suffit 
d'utiliser la commande suivante : 

| $ ./demo-i686.sh 

Le script est extremement simple, nous avons au debut du fichier les lignes suivantes : 

#!/bin/sh 

set -ex 

TARBALLS_DIR=$HOME/downloads 

RESULT_TOP=/opt/crosstool 

export TARBALLS_DIR RESULT_TOP 

GCC_LANGUAGES="c,c++" 

export GCC_LANGUAGES 

# Really, you should do the mkdir before running this, 

# and chown /opt/crosstool to yourself so you don't need to run as root, 
mkdir -p $RESULT_TOP 
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Suite a cela, la generation de la chaine est lancee par la ligne suivante, qui indique que la 
chaine en question sera basee sur la configuration i686, le compilateur gcc-3.4.3 et la 
glibc-2.3.4 : 

eval 'cat i686.dat gcc-3 . 4 . 3-gl ibc-2.3.4.dat ' sh all . sh -notest 

Ce petit exemple n'est cependant pas tres significatif et nous allons construire un script 
demo-at91 . sh permettant de creer une chaine de compilation croisee Linux x86 vers Linux 
ARM ATMEL AT91RM9200. Cette chaine est similaire a celle fournie dans ELDK. 

Au debut du fichier, nous indiquons le repertoire dans lequel CROSSTOOL stockera les 
paquetages telecharges : 

ITARBALLS_DI R= ' pwd ' /downl oads 
export TARBALLS_DIR 
mkdir -p $TARBALLS_DIR 

Ensuite, nous pouvons definir le repertoire destination de la cible : 

IRESULT_TOP=/opt/crosstool 
export RESULT_TOP 
mkdir -p $RESULT_TOP 

Comme pour 1' exemple precedent, la chaine pourra traiter les langages C et C++ : 

IGCC_LANGUAGES="c,c++" 
export GCC_LANGUAGES 

La chaine utilisera le noyau 2.4.27, la configuration du noyau etant definie dans le fichier 
config-kernel : 

I KERNELCONFIG=' pwd' /patches/1 inux-2. 4. 27/config- kernel 
export KERNELCONFIG 

Le repertoire 1 inux-2. 4. 27 n'existe pas dans la distribution CROSSTOOL mais il suffit 
de l'ajouter. Le repertoire contient les differents patches a appliquer au noyau ainsi que le 
fichier de configuration du noyau : 

$ cd patches/linux-2.4.27 

$ Is -w 1 

01_2.4.27-vrsl.patch 

02_2.4.27-vrsl-at91-06102004.patch 

03_2.4.27-mkdep+cross-depmod.patch 

04_2. 4. 27-kbd+sram+f lash. patch 

config-kernel 



Remarque 

Pour que CROSSTOOL considere le fichier comme un patch, le nom du fichier doit obligatoirement contenir la 
chaine de caractere patch ou bien le suffixe .diff. De meme, il est conseille de numeroter les fichiers de 
patch en commengant leur nom par I'ordre d'application (01, 02, etc.). Le lecteur desirant plus d'information 
pourra consulter le code source du script getandpatch .sh . 
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Pour revenir a notre script principal, la cible de la chaine est l'architecture arm-1 inux : 

TARGET=arm-l inux 
export TARGET 
TARGET_CFLAGS="-0" 
export TARGET_CFLAGS 

La chaine de compilation correspondante sera installee dans /opt/crosstool /arm : 

IPREFIX=${RESULT_TOP}/arm 
export PREFIX 

Enfin, nous definissons la liste des paquetages a utiliser : 

BINUTILS_DIR=binutils-2.15 

GCC_DIR=gcc-3.3.4 

GLIBC_DIR=glibc-2.3.2 

GLIBCTHREADS_FILENAME=glibc-linuxthreads-2.3.2 

LINUX_DIR=linux-2.4.27 

export BINUTILS_DIR GCC_DIR GLIBC_DIR GLIBCTHREADS_FI LENAME LINUX_DIR 

La generation de la chaine elle-meme est effectuee par la derniere ligne : 

eval sh all . sh --notest 

Apres avoir lance la generation par la commande demo-at91.sh, nous devons attendre de 
longues heures avant de recolter le fruit de nos efforts. Afin de suivre le deroulement de 
1' execution, il est souhaitable de conserver les traces dans un fichier par la commande : 

$ ,/demo-at91.sh l>build.log 2>&1 & 

On peut de temps en temps suivre revolution de la compilation par la commande : 

$ tail -f build.log 

Lorsque la chaine est generee avec succes nous obtenons le message suivant dans le 
fichier : 

ICross-toolchain build complete. Result in /opt/crosstool/arm. 
testhello: C compiler can in fact build a trivial program. 
Done. 

A partir de la, on peut tester la chaine de compilation comme nous l'avons fait pour ELDK : 

$ PATH=/opt/crosstool/arm/bin:$PATH 

$ export PATH 

$ arm-linux-gcc -v 

Reading specs from /opt/crosstool /arm/1 ib/gcc-1 ib/arm-1 inux/3. 3. 4/specs 

Configured with: /home/ pier re/test/cross tool -0.31/build/arm-l inux/gcc-3.3.4-gl ibc- 

2.3.2/gcc-3.3.4/configure --target=arm-l inux --host=i686-host_pc-l inux-gnu -prefix^/ 

opt/crosstool /arm - -with- header s=/opt /cross tool /arm/arm-1 inux/incl ude --with-local - 

prefix=/opt/crosstool /arm/arm-1 inux --disable-nls --enable-threads=posix --enable- 

symvers=gnu --enable- cxa_atexit --enable-languages=c,c++ --enable-shared --enable- 

c99 --enable-long-long 
Thread model : posix 
gcc version 3.3.4 
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On peut la aussi compiler le programme de test Hello World : 

$ arm-1 inux-gcc -o helloword helloworld.c 

$ file helloworld 

helloworld: ELF 32-bit LSB executable, ARM, version 1 (ARM), for GNU/Linux 2.4.3, 

•dynamically linked (uses shared libs), not stripped 



Utilisation de I'environnement CYGWIN 

La quasi-totalite des outils presentes dans cet ouvrage est utilisable dans un environne- 
ment Linux. Cependant, il est clair que c'est loin d'etre aujourd'hui I'environnement de 
developpement le plus utilise. La plupart des outils commerciaux sont souvent disponibles 
exclusivement sous Windows et la mise en place d'une chaine de developpement sous 
Linux peut poser des problemes dans les grandes entreprises pour lesquelles la gestion du 
pare informatique est centralisee. 

La societe CYGNUS (liee a Red Hat Software) propose depuis longtemps un environne- 
ment sous Windows permettant de porter tres rapidement les applications de Linux vers 
Windows. Le principe est de diriger les appels systeme normalement destines au noyau 
Linux vers une DLL (pour Dynamic Loading Library) Windows fournie par CYGWIN, 
SoitCYGWIN.DLL. 

La majorite des outils disponibles sous Linux sont de ce fait disponibles sous CYGWIN, 
citons entre-autres : 

• les commandes Linux, a commencer par l'interpreteur de commande bash ; 

• la chaine de compilation GNU ; 

• I'environnement graphique XFree86 ; 

• le bureau graphique KDE. 

De ce fait, il est possible a l'aide de CROS STOOL de construire une chaine de compilation 
croisee utilisable sous Windows et CYGWIN et permettant de generer du code ARM. 



Remarque 

A materiel equivalent, il taut cependant noter que la configuration CYGWIN sera moins performante que la 
meme chaine utilisee sur un systeme Linux. De meme, il existe encore quelques problemes dans les adapta- 
tions CYGWIN des environnements graphiques comme KDE. La solution CYGWIN est done a utiliser en dernier 
recours. 



Installation de I'environnement CYGWIN 

La distribution CYGWIN est utilisable sur des environnement Windows recents 
comme Windows 2000 ou Windows XR Elle est disponible sur Internet sur le site 
http://www.cygwin.com. A partir de la page d'accueil du site, on peut telecharger le fichier 
setup . exe qui est une application Windows permettant d' installer la suite de la distribution. 
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Remarque 

II est preferable d'installer CYGWIN sur une partition de type NTFS et non VFAT afin d'eviter certains problemes 
de droits d'acces aux fichiers. On peut connaitre le type de systeme de fichiers en affichant les proprietes 
Windows de la partition en question (utiliser le bouton droit de la souris sur le volume correspondant). 

Lorsque Ton double-clique sur l'icone associee au fichier setup.exe, on obtient la fene- 
tre suivante : 



*■ Cygwin Setup 



ja*i 




Cygwin Net Release Setup Program 

This wizard will guide you through the installation and updating 
of the Cygwin environment and a plethora of GNU packages. 



Setup. ewe version 2.457.2.2 
Copyright 2000, 2001 Red Hat Inc. 
http7/sources. redhat.com/cygwin/ 



< Precedent I Suivant > 



Annuler 



Figure 11-1 

Execution de setup.exe. 

Lors de la premiere installation, il est conseille d'utiliser l'option Install from Internet. 
Les fichiers utilises sont sauves sur le disque local ce qui permettra d'effectuer ulterieu- 
rement une installation a partir d'un repertoire local {Install from Local Directory) si cela 
etait necessaire. 



Cygwin Setup - Choose Installation Type 



Choose A Download Source 

Choose whether to install or download from the internet, or install from files in 
a local directory. 



-jnjxl 



(* Install from Internet 

(downloaded files will be kept for future re-use] 

C D ownload Without I nstalling 
C Install from Local Directory 



< Precedent I Suivant > I Annuler 



Figure 11-2 

Choix du type d' installation. 
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L'ecran suivant permet de selectionner le repertoire d' installation (soit c : \cygwi n par defaut) : 

.Jfijxl 



*■ Cygwin Setup - Choose Installation Directory 



Select Root Install Directory 

Select the directory where you want to install Cygwin. Also choose a few 
installation parameters. 



-Root Directory - 



I C:\cygwin 



Browse.. 



Install For — 
(• All Users 
C Just Me 


Default Text File Type 
P DOS 
(* Unix 



< Precedent I Suivant > 



Annuler 



Figure 11-3 

Choix du repertoire d' installation. 

On selectionne ensuite un serveur miroir de la distribution CYGWIN permettant le char- 
gement des flchiers : 



>- Cyqwin Setup - Choose Download Site(s) 



Choose A Download Site 

Choose a site from this list, or add your own sites to the list 



■Jnjxl 




Available Download Sit' 



ftp://cygwin.dp.ua 

ftp://cygwin.osuosl.org 

ftp://ftp-stud. fht-esslingen. de 

ftp://ftp.ale.org 

ftp://ftp.ce.kmitl.ac.th 

ftp://ftp.cise.ufl.edu 

ftp://ftp.easynet.be 

ftp://ftp.eq.uc.pt 

ftp://ftp.esat.net 

ftp://ftp.fit.vutbr.cz 

ftp://ftp.funet.fi 

ftp://ftp.gwdg.de 

ftp://ftp.iitm.ac.in 




Figure 11-4 

Choix du serveur miroir. 
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Le programme d' installation recupere alors la liste des paquetages et la presente a l'utili- 
sateur. Dans le cas present nous conseillons d'installer la totalite de la distribution : 



*■ Cygwin Setup - Select Packages 


"1 


Select Packages ^^~ 

S elect packages to install |^^_ 




C Keep C Prev <• Curr C Exp View I Category 




1 Category Curr... New Bi... Sr... Package 1^. 




1 +AII© Default 


I + Admin© Default 




1 + Archive© Default 




1 + Base© Default 




1 + Database © Default 




1 + Devel© Default 




+ Doc © Default 




I + Editors© Default 




1 + Games © Default 

1 + Gnome© Default T 






< Precedent 1 Suivant> 1 Annuler 





Figure 11-5 

Liste des paquetages. 

Pour ce faire, il faut cliquer sur le mot Default situe sur la premiere ligne de la liste (com- 
mencant par All). Le programme affiche alors Install a la place de Default dans toute la 
liste, ce qui indique que tous les paquetages sont installes. II faut noter que 1' installation 
de tous les paquetages occupe plus de 2 Go sur le disque. 



Figure 11-6 

Selection des paquetages. 



1 *■ Cygwin Setup - Select Packages 




-In 


"1 


Select Packages 

Select packages to install 




c 






C Keep C 


Prev (* Curr 


C Exp View 1 Category 






Category Curr... New 




Bi... Sr... Package L±. 






+ AIIO Install 








+ Admin 4^ Install 










+ Archive Q Install 










+ Base O Install 










+ Database Q Install 








+ DevelO Install 








1 + Doc# Install 








+ Editors O Install 










+ Games % Install 










+ Gnome O Install 

<i I 




J 






< Precedent 


1 Suivant > 1 Annuler 
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Si Ton clique sur Suivant, l'installation doit demarrer. En cas de blocage de 1' installation 
a cause d'un probleme d'acces reseau, il est possible d'interrompre le programme d'ins- 
tallation puis de l'executer de nouveau. L'installation reprendra au niveau du dernier 
paquetage installe. 

Lorsque l'installation est terminee, on doit obtenir une icone Cygwin sur le bureau Win- 
dows, ce qui permet d'ouvrir le terminal CYGWIN qui a une fiere allure de bon vieux 
terminal Linux : 



njxj 




Figure 11-7 

Terminal CYGWIN. 



En premier lieu, il faut executer la commande rebaseal 1 - v dans le terminal. Cette com- 
mande est necessaire car elle permet d'affecter une adresse de base unique aux differen- 
tes DLL et done permettre un chargement ordonne des bibliotheques. 

On peut ensuite demarrer l'environnement XFree86 qui par defaut affiche un emulateur 
de terminal xterm. A partir de ce terminal, on peut lancer les commandes Linux habituelles 
comme le montre la figure 11-8. 
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Figure 11-8 

Environnement CYGWIN. 



Creation de la chaine de compilation croisee pour ARM 

L' environnement Linux quasiment complet disponible, la procedure de generation de la 
chaine croisee CROSSTOOL est identique a celle utilisee sous Linux, decrite plus haut 
dans ce meme chapitre. II faut noter cependant que le type de plate -forme de developpe- 
ment detecte par le script de configuration configure est maintenant i686-host_pc- 
cygwin au lieu de i686-pc-linux-gnu. 



Attention 

Les scripts de CROSSTOOL ne s'entendent pas forcement tres bien avec les noms de repertoires contenant des 
espaces, ce qui est frequent sous Windows. II est done preferable d'extraire I'archive CROSSTOOL dans un 
repertoire ayantun nom UNIXcomme /home/test etnon pas /home/mon repertoire. 



Developpement croise 

Chapitre 1 1 

Apres quelques heures de compilation (!), on obtient la meme chaine de developpement 
contenant le compilateur arm-linux-gcc. On peut y acceder de la meme maniere que 
sous Linux : 

$ export PATH=/opt/crosstool/arm/bin:$PATH 

$ arm-linux-gcc -v 

Reading specs from /opt/crosstool /arm/lib/gcc-lib/arm-1 inux/3.3.4/specs 

Configured with: /home/test /cross tool -0.31/build/arm-linux/gcc-3.3.4-gl i be -2. 3. 2/ 

gcc-3.3.4/configure --target=arm-l inux --host=i686-host_pc-cygwin --prefix=/opt/ 

cross tool /arm --with-headers=/opt /cross tool /arm/arm-1 inux/include --with -local - 

prefix=/opt/crosstool /arm/arm-1 inux --disable-nl s --enable-threads=posix --enable- 

symvers=gnu --enable- cxa_atexit --enable-1 anguages=c,c++ --enable-shared --enable- 

c99 --enable-long-long 
Thread model : posix 
gec version 3.3.4 

Et Ton peut bien stir compiler l'exemple de la meme maniere : 

$ pwd 

/home/John Doe 

$ arm-linux-gcc -o helloworld helloworld.c 

$ file helloworld 

helloworld: ELF 32-bit LSB executable, ARM, version 1 (ARM), for GNU/Linux 2.4.3, 

•dynamically linked (uses shared libs), not stripped 

Exemple de compilation 

Lorsqu'une chaine de compilation est installee, il est possible de construire des outils a 
partir des paquetages. Voici quelques exemples, dont un noyau Linux utilisable sur archi- 
tecture ARM. 

Compilation d'un noyau Linux ARM/AT91 RM9200 

L' architecture ARM est supportee par le noyau Linux mais il est necessaire d'appliquer 
des patches disponibles sur http://www.arm.linux.org.uk/developer. 

Dans le cas d'un noyau 2.4.27, on doit tout d'abord extraire l'archive du noyau standard 
(voir chapitre 4) puis appliquer le patch generique ARM puis le patch specifique au com- 
posantAT91RM9200: 

I# cd linux-2.4.27 
# patch -pi < 2.4.27-vrsl.patch 
§ patch -pi < ../linux-patch/02_2.4.27-vrsl-at91-06102004.patch 

La suite est tres similaire a la compilation d'un noyau natif sauf que Ton doit utiliser les 
variables d'environnements ARCH et CR0SS_C0MPILE pour specifier la chaine de develop- 
pement croisee. Pour configurer le noyau on utilisera la commande suivante : 

| # make ARCH=arm CR0SS_COMPILE=arm-l inux- menuconfig 
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Pour le compiler on utilisera la commande suivante : 

| # make ARCH=arm CROSS_COMPILE=arm-l inux- dep zlmage modules 

Enfin, pour installer les modules sur un repertoire image de la cible, on utilisera la com- 
mande suivante : 

| # make ARCH=arm CROSS_COMPILE=arm-l inux- INSTALL_MOD_PATH=/target_arm modules_install 

Programme gdbserver 

Cet outil a ete decrit au chapitre 7. II permet de deboguer un programme execute sur la 
cible depuis le poste de developpement a travers un lien reseau ou RS-232. Pour generer 
la version ARM on utilisera les commandes suivantes dans le repertoire des sources de 
gdbserver : 

1$ ./configure --build=i686-pc-l inux-gnu --host=arm-l inux 
$ make 

Debogueur GDB croise 

Un tel outil permettra de deboguer a distance un programme execute sur une cible ARM 
via T outil precedent : 

1$ ./configure --prefix=/opt/crosstool/arm --target=arm-linux --program-prefix=arm-linux- 
$ make 

Debogueur GDB natif ARM 

La commande suivante permet de construire une version de gdb directement utilisable sur 
la cible ARM : 

1$ ./configure -build=i686-pc-l inux-gnu --host=arm-l inux --prefix=/usr/local /bin 
$ make 

Bibliotheque NCURSES native ARM 

Nous construisons ici une version ARM de la bibliotheque NCURSES qui pourra etre 
ajoutee a la chaine de compilation : 

1$ BUILD_CC=gcc CC=arm-l inux-gcc configure -build=i686-pc-l inux-gnu --host=arm-l inux 
**--prefix=/opt /cross tool /arm/arm-1 inux --with -shared 
$ make 
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Resume 



La creation de la chaine de compilation est une etape essentielle de la mise en place de 
l'environnement de developpement en cas d'utilisation d'une cible d' architecture diffe- 
rente. La construction entierement manuelle d'une chaine de compilation croisee est fas- 
tidieuse. 

Pour certaines architectures, il existe des chaines de compilation croisees au format 
binaire et tres faciles a installer (ELDK) mais il est possible de construire sa propre 
chaine a l'aide de l'outil CROSSTOOL. 

L'environnement CYGWIN permet d'utiliser les outils Linux sous Windows 2000 ou XP. 
Les performances sont inferieures a celle de Linux mais 1' utilisation de CROSSTOOL 
est strictement identique a celles de Linux. II est done tres simple de construire une 
chaine de developpement croisee utilisable sous Windows/Cygwin. 
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Interfaces graphiques 



Mode texte (console standard) 

L'interface graphique est souvent un probleme mineur dans le cas d'une application 
embarquee. Bien des systemes embarques n'utilisent pas de console au sens PC du terme 
(un ecran et un clavier). Dans le chapitre 5, on a d'ailleurs montre comment on peut confi- 
gurer le noyau Linux et LILO pour rediriger la console du systeme sur un port serie. Dans 
ce type de systeme, l'interface utilisateur est reduite aux actions de maintenance via une 
connexion locale sur la console, ou distante a travers un reseau, et les protocoles Telnet, 
SSH ou FTP. 

Le paquetage console-tools inclut des outils de manipulation du clavier et de 1' ecran de la 
console Linux. Ce paquetage contient entre autres l'utilitaire loadkeys et les fichiers de 
configuration des differents claviers nationaux. Cet utilitaire a deja ete utilise au chapi- 
tre 6 pour configurer le clavier francais. L adaptation d'un nouveau clavier passe par la 
creation d'un fichier map (carte) permettant de faire le lien entre le code materiel envoye 
par la touche (scancode ou keycode) et le code ASCII a afficher dans la police de caracte- 
res choisie. Le programme showkey permet de connaitre les codes des touches. 

# showkey 

press any key (program terminates after 10s of last keypress)... 

keycode 28 released 

keycode 16 press 

keycode 16 release 

Le programme dumpkeys permet de visualiser la carte du clavier utilisee par loadkeys. 
Une fois la carte stockee dans un fichier, on peut 1' adapter au clavier reel puis utiliser la 
nouvelle carte avec loadkeys. 

I# dumpkeys > monclavier 
# cp monclavier nouveauclavier 
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Apres modification du fichier nouveau_clavier en fonction des valeurs de codes obte- 
nues par show keys, on peut executer : 

| # loadkeys nouveaucl avier 

On peut egalement modifier la police de caracteres de la console en utilisant la com- 
mande consol echars. Cette modification n'est pas qu'esthetique et peut se reveler neces- 
saire dans le cas de langues n'utilisant pas l'alphabet latin. Ainsi, pour passer a une 
police en alphabet cyrillique, on pourra faire : 

# consolechars -f UniCyr_8xl4 

et, pour revenir a la police par defaut : 

# consolechars -d 

Les fichiers correspondant aux polices de caracteres sont situes sur /lib/kbd/console- 
fonts. Nous ne donnons ici, bien entendu, qu'un petit apercu des manipulations possi- 
bles et le lecteur plus exigeant pourra se referer au document Keyboard-and-Console- 
HOWTO disponible sur http://www.linuxdoc.org. 

X Window System 
Une introduction a X 

X Window System est traditionnellement l'environnement graphique de predilection 
pour les systemes de type Unix. Concu dans les annees 1980 dans les laboratoires du 
MIT (Massachusetts Institute of Technology), sa vocation initiale etait de constituer un 
systeme graphique « reparti » constitue de terminaux graphiques banalises (ou DIS- 
PLAY) equipes d'un logiciel appele « serveur X ». Le serveur X recoit a travers le reseau 
des requetes graphiques des « clients X » que sont les programmes applicatifs executes 
sur des systemes distants. Le serveur X et les clients peuvent bien entendu etre situes sur 
la meme machine physique, ce qui est tres souvent le cas. 




machine 
hbte 




i client X 




protcecieX 

iiiiiiiiiiiiiiiiiiiiiiiint client a. 



iiiiiiiiiiiiiiiiiiiiiiV cli6nt a. 



Figure 12-1 

Architecture X Window System. 
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Le terminal ou DISPLAY est constitute d'un trio ecran/clavier/souris. La conception du 
systeme etait tres novatrice a l'epoque car les architectures materielles et logicielles tant 
du terminal X recevant les requete graphiques que du serveur executant les applications 
peuvent etre tres differentes. De meme, le support de transport du protocole X est bana- 
lise, bien qu'il soit souvent base sur une connexion TCP/IP. Au niveau du client, l'acces 
aux differentes couches de X est assure par des bibliotheques, comme cela est indique sur 
la figure ci-apres : 



Toolkits (Xaw, Xm) 



Xt 



Xlib 



Protocole X 



Figure 12-2 

Les bibliotheques X. 



Le protocole X est defini sous forme de valeurs hexadecimales et il n'est bien sur jamais 
utilise directement par les developpeurs X. La Xlib (1 ibXll) est l'interface de ce proto- 
cole avec l'API de programmation X mais elle ne permet d'effectuer que des operations 
elementaires, telles que le trace de polygone ou l'affichage d'une chaine de caracteres. 
La bibliotheque Xt (libXt, appelee aussi Intrinsics) definit des classes de base d'objets 
graphiques. Ces classes de bases sont ensuite utilisees par les « toolkits » comme Xaw 
(1 ibXaw, Athena Widgets, du nom du projet Athena associe au developpement de X) ou 
Motif, developpe par l'OSF (Open Software Foundation, http://www.opengroup.org). A 
vocation commerciale initialement, ce toolkit est desormais diffuse en Open Source sur 
http://www. openmotif. org. 

Le systeme X a cependant un defaut notoire ; en effet, de par sa grande flexibilite et son 
independance par rapport au materiel, il est relativement couteux en ressources materiel- 
les et a longtemps ete reserve aux stations graphiques haut de gamme. Notez cependant 
que X est egalement un logiciel Open Source quoique non-GPL. La licence de X est 
d'ailleurs moins restrictive que la GPL. Des informations generates sont disponibles sur 
le site officiel de X Window System, soit http://www.x.org. Le site de Kenton Lee (http:// 
www.rahul.net/kenton), celebre consultant specialiste de X, est egalement une mine de 
renseignements et d' articles. 

En raison des contraintes induites par le transport de requetes graphiques a travers le 
reseau, le fait est que bon nombre de systemes X sont aujourd'hui constitues d'un serveur 
et de clients situes sur la mime machine physique. La complexite amenee par la gestion 
du systeme distant est done peu utilisee bien que celle-ci penalise les performances. 
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Un portage de X pour les architectures Unix/x86 est depuis longtemps disponible via le 
projet XFree86 (http://www.xfree86.org). La complexite d'une architecture de type x86 est 
principalement due a la multitude de cartes graphiques disponibles, contrairement aux 
anciennes stations de travail proprietaires pour lesquelles la carte graphique etait fournie 
par le constructeur de la station. 

Par rapport au sujet qui nous occupe dans cet ouvrage (Linux embarque), nous voyons 
bien qu'il existe une reelle contradiction dans l'utilisation d'une couche graphique pour 
ce type de systeme : la couche graphique de predilection est par nature lourde, et done 
difficile a integrer dans un environnement reduit mais e'est cependant celle pour laquelle 
nous aurons le plus de choix concernant les logiciels disponibles. Pour ne citer qu'un 
exemple, bon nombre de plug-ins permettant de gerer des formats proprietaires mais tres 
repandus, comme le PDF (Portable Document Format) ou le Flash Macromedia, sont le 
plus souvent disponibles pour le systeme graphique X. 

Reduction du systeme X 

Un systeme graphique comme X est souvent en marge de la configuration d'un systeme 
embarque, etant considere comme « externe » au systeme d' exploitation lui-meme. C'est 
en partie vrai car la structure de Linux fait qu'il n'y a pas d'imbrication directe entre les 
couches graphiques et les couches systeme indispensables. L'avantage evident en est, 
bien entendu, que Ton peut avoir un systeme Linux fonctionnel sans aucune autre inter- 
face que le mode texte, et done de tres faible faille. La consequence directe en est toute- 
fois le relativement faible interet que les editeurs principaux de distributions Linux 
embarques portent a la partie X. Nous verrons dans la suite du chapitre que la situation 
evolue avec 1' apparition de nouveaux systemes graphiques (comme Qt) non bases direc- 
tement sur la technologie X et done souvent mieux adaptes a un environnement reduit. Le 
fait est que la reduction de X est complexe et surtout extremement liee a 1' environnement 
de la cible. Des ouvrages entiers sont consacres a X et XFree86, et il est vrai que nous 
sommes a la limite de la technologie Linux embarquee a part entiere (les problemes 
seraient les memes sur d'autres systemes comme FreeBSD). 

Dans cette section, nous nous efforcerons done de rester assez generaux meme si une 
solution concrete et fonctionnant dans la majorite des cas sera finalement presentee. 



Remarque 

Au moment de la redaction de cet ouvrage, deux versions de XFree86 (la 3 et la 4) cohabitent encore sur certaines 
distributions, meme si XFree86-4 prend largement le pas sur I'autre version de par sa structure plus modulaire 
au niveau des drivers. Les exemples que nous presentons sont exclusivement bases sur XFree86-4. 



Les composants installes par les paquetages XFree86 d'une distribution classique Red 
Hat 7.2 occupent un espace assez volumineux, d'environ une centaine de Mo. Dans le cas 
de la distribution Red Hat 7.2, tous les composants XFree86 sont installes par des paquetages 
RPM du type XFree86-nom_package.i386.rpm. 



Interfaces graphiques 

Chapitre 12 



§ rpm -qa | grep XFree86 
XFree86-IS08859-15-100dpi-fonts-4. 1.0-3 
XFree86-libs-4. 1.0-3 
XFree86-xfs-4. 1.0-3 
XFree86-75dp1 -Fonts -4. 1.0-3 
XFree86-IS08859-15-75dpi-fonts-4. 1.0-3 
XFree86-twm-4. 1.0-3 
XFree86-xdm-4. 1.0-3 
XFree86-4. 1.0-3 

§ du -s /usr/XllR6 
102828 /usr/XllR6 

II est evident que, dans le cas d'un systeme embarque, nous installerons uniquement les 
composants indispensables a notre application. Si nous detaillons un peu la structure de 
XFree86, il apparait que le systeme est compose des elements suivants : 

• le serveur X 

• les clients X 

• les bibliotheques X 

• les polices de caracteres 

• divers autres fichiers de configuration dont le fichier principal de configuration du 
serveur qui est souvent /etc/Xll/XF86Config ou /etc/Xll/XF86Config-4. 

Concernant la methodologie de reduction du systeme X, le principe applique sera done a 
peu pres le meme que s'agissant de la reduction du systeme Linux lui-meme. 

Le serveur X est quant a lui indispensable mais on peut reduire son empreinte memoire 
en selectionnant uniquement les pilotes graphiques adaptes au materiel et les « exten- 
sions » indispensables a notre application (dans une installation Linux classique, plu- 
sieurs pilotes peuvent etre installes par defaut). Si nous comparons une version complete 
a une version reduite, nous pouvons constater que le rapport est d' environ 20. 

# du -s /usr/XHR6. gen/lib/modules 
1156 /usr/XHR6. gen/lib/modules 

# du -s /usr/XllR6.orig/l ib/modules 
21004 /usr/XllR6.orig/l ib/modules 

Ce type d' optimisation, tres spectaculaire, peut etre obtenue en utilisant la carte graphique 
en mode VESA {Video Electronics Standards Association, http://www.vesa.org). L association 
VESA a publie un standard de BIOS graphique (VBE pour VESA BIOS Extension) per- 
mettant d'utiliser toutes les cartes graphiques compatibles VBE avec un jeu d' instructions 
commun. La version courante est la 3.0, le standard etant disponible en telechargement 
sur http://www.vesa.org/vbelink.html. XFree86 necessite des cartes compatibles VBE 2.0 pour 
fonctionner, ce qui est le cas de la quasi-totalite des chipsets graphiques du commerce. Le 
mode VESA est disponible en installant un minimum de modules pour XFree86. 

I§ pwd 
/usr/XllR6/lib/modules 
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# Is -1 




















total 756 
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# Is -1 drivers/ 
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De meme, concernant le fichier XF86Config, on selectionnera le pilote en configurant la 
section Devices comme suit : 

Section "Device" 

Identifier "MyVidCard" 

Driver "vesa" 

VideoRam 2048 

# Insert Clocks lines here if appropriate 
EndSection 

Le mode VESA est cependant moins performant que les modes acceleres des cartes 
recentes. En cas de besoin reel de hautes performances, il conviendra d'effectuer la con- 
figuration du serveur X en fonction du mode accelere. 

Selon la selection des clients et des applications X locales au systeme, on peut en deduire 
les bibliotheques necessaires et done celles que Ton peut supprimer. Pour cela, on peut 
utiliser le script mkl i bs . sh decrit au chapitre 5. Comme on a pu le preciser, ce script ne 
resoudra cependant pas les problemes des bibliotheques chargees lors de 1' execution. La 
seule solution dans ce cas consiste a travailler de maniere empirique en effectuant des 
modifications du fichier XF86Config, en ajoutant ou supprimant des modules au fur et a 
mesure et en validant les modifications par un test du type : 

xinit -- -depth 16 

En fonction des memes criteres, on peut selectionner les polices de caracteres a conserver. 
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Par defaut, XFree86-4 utilise un programme « serveur » de fontes appele xf s (X Font 
Server). Cela se traduit par la ligne de configuration suivante : 

FontPath "unix/:7100" 

la configuration reelle etant deportee dans le fichier /etc/Xll/fs/conf ig du programme 
xf s. Dans le cas d'une version reduite, nous n'utiliserons pas xf s et les polices de carac- 
teres seront directement declarees dans le fichier XF86Config. 

I FontPath Vusr/X11R6/1 ib/Xll/fonts/misc/" 

FontPath Vusr/X11R6/1 ib/Xll/fonts/75dpi/ : unseal ed" 
FontPath Vusr/X11R6/1 ib/Xll/fonts/75dpi/" 

Le nombre de polices doit done etre precisement defini en fonction des besoins de 
l'application mais, en toute rigueur et independamment des considerations d'esthetique, 
un serveur X a besoin d'une seule police pour fonctionner (la police est definie comme 
fixed). Au total, l'empreinte memoire necessaire pour un systeme X reduit est de l'ordre 
de 8 Mo, sachant que la liste des clients disponibles est reduite au strict minimum. 



2166 avr 23 16:08 startx 

153915 avr 19 12:55 twm 

7 mai 6 11:42 X -> XFree86 

35736 avr 19 12:55 xauth 

1746388 avr 19 12:56 XFree86 

14155 avr 19 12:55 xinit 

11919 avr 19 12:55 xkill 

37427 jun 6 2001 xmodmap 

32494 jun 6 2001 xrdb 

177496 jan 8 2000 xterm 

891516 avr 22 13:43 Xvesa 



§ cd /usr/XHR6/bin 




# Is -1 
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# du -c -s /usr/XHR6 /etc/Xll 
7844 /usr/XHR6.gen 
632 /etc/Xll. gen 

8476 total 



Un serveur X minimal (Xkdri ve) 

Independamment de l'empreinte memoire sur le disque, X est relative ment gourmand en 
memoire vive. Les sources de XFree86-4 incluent cependant un serveur tres optimise tant 
au niveau de l'empreinte memoire que de la RAM utilisee a 1' execution. Le serveur 
Xkdri ve contient quelques limitations, par exemple l'absence de support des polices vec- 
torielles. Autre limitation : il ne fonctionne que sous Linux/x86 et pour un nombre limite 
de chipsets graphique. II fonctionne cependant tres bien en mode VESA ou bien en utili- 
sant le frame-buffer Linux decrit a la section suivante. La page de manuel associee est 
disponible en ligne sur http://www.xfree86.Org/current/Xkdrive.1.html. 
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Contrairement aux autres composants, ce serveur Xkdri ve n'est en general pas disponible 
sur les paquetages RPM binaires des distributions classiques et la meilleure solution est 
de partir directement des sources de XFree86-4. Pour cela, il faut choisir un bon miroir, 
comme ftp://ftp.free.fr. 

# ncftp ftp.free.fr 

NcFTP 3.0.0 beta 21 (October 04, 1999) by Mike Gleason (ncftp@ncftp.com). 

Connecting to 212.27.32.12... 

ProFTPD 1.2.1 Server (ProFTPD) [ftpmirror.proxad.net] 

Logging in. . . 

Anonymous access granted, restrictions apply. 

Logged in to ftp.free.fr. 

ncftp / > cd mi rrors/ftp.xf ree86.org/XFree86/4.2.0/source 

ncftp . . .g/XFree86/4.2.0/source > dir 
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X420src-l.tgz 
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X420src-2.tgz 
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X420src-3.tgz 



Les sources sont divisees en trois archives X420src-X.tgz qu'il faut rapatrier. Apres 
extraction des trois archives, on obtient le repertoire xc contenant entre autres le fichier 
de documentation INSTALL-X.org. Le but n'etant pas de construire entierement XFree86-4 
mais seulement le serveur Xkdrive, il faut creer un fichier host.def sur le repertoire xc/ 
conf ig/cf. Ce fichier a 1' allure suivante : 

#define BuildServersOnly YES 
#define KDriveXServer YES 
#define TinyXServer YES 
#define XfbdevServer NO 
#define XvesaServer YES 
#define BuildTypel YES 

On lance ensuite la compilation en executant : 

make World >& world.log 
et on peut surveiller la compilation en lancant : 

tail -f world.log 
Lorsque la compilation est terminee avec succes, on doit avoir a la fin de worl d . 1 og : 

Full build of Release 6.6 of the X Window System complete. 
Le fichier Xvesa doit egalement etre construit. 



$ Is -1 programs/Xserver/Xvesa 
-rwxrwxr-x 1 pierre pierre 



838540 mai 3 14:31 programs/Xserver/Xvesa 
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On note la taille relativement modeste de cet executable (« seulement » 800 Ko) par rap- 
port a la version standard. On peut tester le serveur en executant : 

# Xvesa -screen 1024x768x16 & 

qui utilisera une resolution de 1024 sur 768 pixels en mode 16 bits (65 536 couleurs). 

frame-buffer (console graphique) 

Nous avons vu pour l'instant que la seule solution pour utiliser Linux en mode graphique 
etait de passer par X Window System. Meme si X peut etre reduit pour convenir a un 
environnement embarque, il ne represente pas forcement la meilleure solution. 

La console graphique ou frame -buffer permet de piloter les modes graphiques haute reso- 
lution directement depuis le noyau Linux, ce qui n'est pas le cas de la majorite des ser- 
veurs X qui le font en mode utilisateur. Une des applications principales du frame-buffer 
est la possibility d'afficher un logo de pingouin au demarrage de LINUX mais nous 
allons voir que ce n'est pas la seule. 

Configuration du frame-buffer 

Le support frame -buffer doit etre active via la procedure standard de configuration du 
noyau Linux en utilisant le menu Console drivers/Frame-buffer. On obtient alors l'ecran 
decrit ci-apres : 
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Figure 12-3 

Configuration du frame -buffer. 
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Comme dans le cas de X, le mode VESA est disponible a condition que le chipset graphi- 
que soit compatible VBE 2.0 ou superieur. Certaines cartes comme les MATROX ou les 
ATI disposent egalement de pilotes specifiques bien qu'elles fonctionnent egalement en 
mode VESA. La description des differents modes graphiques accessibles en mode VESA 
est disponible dans le fichier Documentation/fb/ vesafb.txt des sources du noyau 2.4. 
Si Ton veut valider le support d'une carte graphique particuliere (non-VESA), il faudra 
cocher 1' option correspondante. 

Lorsque le noyau est compile et installe, on peut utiliser LILO pour indiquer le mode gra- 
phique a utiliser au demarrage. 

Par defaut, LILO utilise la ligne suivante pour demarrer le systeme en mode texte : 

vga = NORMAL 

Le document vesafb.txt donne la liste des codes a utiliser en fonction des resolutions 
graphiques et des nombres de couleurs, de 256 a 16 millions. 





Tableau 12-1 


Codes VESA 


pour 


frame-buffer. 






640 x 480 


800 x 600 




1024x768 


1280x1024 


256 


0x301 


0x303 




0x305 


0x307 


32 K 


0x310 


0x313 




0x316 


0x319 


64 K 


0x311 


0x314 




0x317 


0x31 A 


16 M 


0x312 


0x315 




0x318 


0x31 B 



Si le fichier /etc/1 i 1 o . conf est modifie en ajoutant la ligne : 

vga = ASK 

l'utilisateur devra saisir la valeur hexadecimale du mode graphique lors du demarrage du 
systeme, soit par exemple 317 pour une resolution de 1024x768 en 64 K couleurs 
(16 bits). Si Ton desire utiliser un mode graphique en permanence, on pourra utiliser une 
section LILO du style : 

image=/boot/bzImage-2.4.18_fb_vesa 

# 1024x768xl6bpp 
vga=791 

# 640x480xl6bpp 

# vga=785 

# 800x600xl6bpp 

# vga=788 

label =linuxl8fbv 

read-only 

root=/dev/hda4 

Dans ce cas, la valeur doit etre convertie en decimal car LILO ne gere pas les valeurs 
hexadecimales. Si tout se passe bien, le systeme doit basculer en mode graphique et 
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afficher le logo du petit pingouin. On peut egalement configurer le mode graphique en 
passant l'option video= a LILO lors du demarrage du systeme soit par exemple : 

LILO: linuxl8fbv video=vesa: 1024x768-16 

pour le meme mode graphique 1024 x 768 x 16 bpp. La ligne pourra bien entendu etre 
ajoutee systematiquement avec une directive APPEND dans le fichier /etc/1 ilo.conf. 
Dans le cas d'une carte ATI Mach64 en mode non VESA, on utiliserait : 

LILO: linuxl8fbv video=atyfb: 1024x768-16 

Manipulation du frame-buffer 

Lorsque le frame-buffer est fonctionnel, il est disponible via le device /dev/fbO. La 
notion de fichier banalise permet d'effectuer une copie d'ecran en operant une simple 
copie du device vers un autre fichier. 

cp /dev/fbO /tmp/test.raw 

On obtient alors un fichier en format binaire correspondant au contenu de la memoire du 
frame -buffer. On peut le convertir dans un format plus sympathique en utilisant le petit 
programme r§w2ppm qui suit : 

#include <stdio.h> 

#1nclude <std1ib.h> 

int mainO'nt argc, char *argv[]) { 

int len; 

unsigned short buf [256] ; 

FILE *f; 

int w, h; 

w = 640; 

h = 480; 



printf("P6\n^d 2d\n255\n" , w, h); 
f = fopen(argv[l] , "rb"); 
while (den = fread(buf, 2, 256, f)) 
int i ; 

for (i = 0; i < len; i++) { 
unsigned char r, g, b; 

#ifdef BYTESWAP 

/* Swap the byte order */ 

buf[i] = ((buf[i] & OxffOO) » I 

#endif 

r = (buf[i] & 0xF800) » 8; 

g = (buf[i] & 0x07E0) » 3; 

b = (buf[i] & OxOOlF) « 3; 
printf("%cSSc%c", r, g, b); 
} 



0) 



!) + ((buf[i] & OxOOff) « 8); 
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On en deduit l'enchainement de commandes qui conduit a un fichier PNG facilement 
manipulable. 

raw2ppm /tmp/test.raw | pnmtopng > /tmp/test.png 

Les toolkits graphiques 

Dans la partie consacree a X, nous avons cite les toolkits ATHENA et MOTIF largement 
utilises dans les applications habituelles. Les criteres d'une application embarquee sont 
cependant tres differents, et nous voyons apparaitre de plus en plus d'outils dedies a un 
environnement embarque, particulierement sous Linux. En laissant de cote MOTIF et 
ATHENA, nous allons ici decrire brievement le toolkit commercial Qt/Embedded edite 
par Trolltech et le projet Micro Windows/NanoX. 

Qt/Embedded 

La societe norvegienne Trolltech (http://www.trolltech.com) developpe depuis plusieurs 
annees le toolkit Qt. Initialement developpe pour Unix et 1' environnement XI 1, Qt est un 
toolkit multi-plate -forme qui permet de realiser des applications graphiques portables 
entre des environnements Unix, Windows et MacOS. Qt est a la base du bureau KDE 
(http://www.kde.org), tres utilise sous Linux. Qt est aussi le « concurrent » direct de GTK 
(http://www.gtk.org), a la base du bureau GNOME (http://www.gnome.org). Notez qu'il 
existe une version de GTK tournant sur le frame-buffer Linux (voir http://developer. 
gnome. org/doc/API/2. 0/gtk/gtk-framebuffer. html) . 

La societe Trolltech a recemment etendu son developpement en realisant une version de 
Qt appelee Qt/Embedded, adaptee a un environnement Linux embarque et pouvant uti- 
liser le frame -buffer decrit precedemment. Qt et Qt/Embedded sont des produits com- 
merciaux mais il existe des versions GPL strictement identiques aux distributions 
commerciales, mis a part le fait qu'elles n'existent que pour 1' environnement Unix et pas 
pour Windows ni MacOS. Notez que la licence utilisee est la GPL et non pas la LGPL 
(Lesser GPL) ce qui limite 1' utilisation des versions GPL de Qt et Qt/Embedded a des 
applications elles-memes sous GPL. La version GPL de QT/Embedded est disponible a 
l'adresse http://www.trolltech.com/download/qtembedded.html. 

Cette page rappelle clairement les termes de la licence d'utilisation de la version libre de 
Qt/Embedded. Apres extraction de l'archive, on obtient le repertoire qt- embedded -f ree- 
3.3.3. Pour preparer la compilation, on doit se positionner sur le repertoire et valider les 
variables d' environnement QTDIRet LD_LIBRARY_PATH. 

Icd qt-embedded-free-3.3.3 
export QTDIR=~pwd~ 
export LD_LIBRARY_PATH=$QTDIR/lib:$LD_LIBRARY_PATH 
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On doit ensuite configurer l'environnement en utilisant le script configure auquel on 
peut passer differentes options. La liste des options est disponible en executant : 

./configure --help 



Attention 

Pour generer correctement la bibliotheque et les exemples, il est indispensable de specifier la liste des « profon- 
deurs » de frame-buffer utilisables (8, 16, 24 ou 32 plans). 



Pour ce faire, on utilisera la ligne : 

./configure -depths 16,24,32 

sachant que Trolltech annonce que le support 8 plans est experimental. Apres avoir 
repondu aux quelques questions en validant les reponses par defaut, on peut enfin taper 
make pour generer la bibliotheque et les exemples. Notez que Qt/Embedded est entiere- 
ment ecrit en C++, ce qui entraine un temps de compilation assez long compare au C. 

Lorsque la compilation est terminee, on peut aller dans le repertoire des exemples et lan- 
cer le demonstrateur. 



I# cd examples/launcher 
# ./start_demo 

L'ecran affiche a 1' allure suivante 



Q 




Qt/Embedded 



This display is a simple Qt/Embedded ^ 
launcher application, running directly on the 
Linux console. The buttons and listbox to the 
right invoke additional applications. 



Less is more 

Qt/Embedded is modular and scalable. You 
can assemble the Qt features you really need 
and leave the others out. Since Qt/Embedded 
is not based on XI 1 it has substantially lower 
memory requirements than XI 1 . By picking 
and choosing features, the memory demands 
of Qt/Embedded can be tuned from 1 Mb to 3 
Mh inHDMrTntpl rRfil 

Figure 12-4 

Demonstrateur Qt/Embedded. 
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Si Ton clique sur le mot widgets a la fin de la liste deroulante de droite, on obtient l'ecran 
suivant qui donne un apercu des differents objets graphiques disponibles sous Qt/Embed- 
ded. On remarquera que ces objets sont identiques a ceux de Qt. 
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Figure 12-5 

Widgets Qt/Embedded. 

GTK-Embedded 

Cette bibliotheque a pour origine l'outil d' edition graphique GIMP. A Pepoque elle fut 
creee comme alternative fibre (et plus performante) a la bibliotheque OSF-Motif qui etait 
alors proprietaire. Depuis, elle a servi de base a l'environnement GNOME. Cette biblio- 
theque est ecrite en langage C et elle est diffusee sous licence LGPL, ce qui permet de 
l'utiliser pour ses propres developpements sans obligatoirement placer son propre code 
sous GPL. Au niveau des fonctionnalites, elle est relativement proche de Qt et sera done 
reservee aux applications graphiques relativement complexes. 

La compilation de GTK+ est plus complexe que celle de Qt car elle necessite la presence 
de plusieurs bibliotheques annexes pour fonctionner (soit Glib, Pango et ATK). Ces 
bibliotheques sont disponibles en telechargement sur le site de GTK+ (http://www.gtk.org). 
Pour ce test, nous avons utilise les versions suivantes des bibliotheques : 

• atk-1.8.0 



glib-2.4.8 
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• gtk+-2.4.14 

• pango- 1.4.1 

II faut tout d'abord compiler la bibliotheque glib en utilisant la procedure classique, soit : 

1$ ./configure -prefix=/usr 
$ make 
# make instal 1 

On peut ensuite faire de meme pour les bibliofheques Pango et ATK. 

Pour la bibliotheque GTK+, il faut indiquer que Ton va utiliser le frame -buffer et non la 
sortie XI 1 qui est la configuration par defaut. Avant cela, il faut appliquer un petit patch 
a la bibliotheque car il semble y avoir un probleme de fonction non definie si Ton utilise 
la sortie frame -buffer. II est inspire d'un patch diffuse pour GTK+-2.4.0 par Frederic 
Crozat (developperu de Mandriva) mais il semblerait que celui-ci n'ait pas ete pris en 
compte par les developpeurs de GTK+. Le patch est disponible dans l'espace de tele- 
chargement de l'ouvrage (www.editions-eyrolles.com). 

La procedure de compilation est done la suivante, tout d'abord l'application du patch a 
partir du repertoire des sources. : 

$ patch -pO < /tmp/gtk_2.4.4_linux-fb.patch 

patching file gdk/1 inux-fb/gdkdrawable-fb2.c 

patching file gdk/1 inux-fb/gdkfont-fb.c 

patching file gdk/1 inux-fb/gdkwindow-fb.c 

Ensuite viennent la generation de l'environnement via configure en precisant la sortie 
frame -buffer, puis la compilation et enfin 1' installation : 

1$ ./configure --prefix=/usr --with-gdktarget=l inux-fb 
$ make 
§ make instal 1 

Lorsque tout est installe on peut utiliser le programme de demonstration present dans le 
repertoire demos/gtk-demo des sources de GTK+. Ce programme doit bien entendu etre 
appele depuis la console frame -buffer Linux en ayant pris soin de stopper le service gpm 
(qui gere la souris en mode texte) si ce dernier etait actif . 

I# cd demos/gtk-demo 
# ./gtk-demo 

L' execution du programme de test provoque l'affichage de la fenetre presentee sur la 
figure page suivante. 
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Figure 12-6 

Demonstration de GTK-Embedded. 



Microwindows et Nano-X 

A la difference de Qt/Embedded, Micro Windows et Nano-X sont des produits non com- 
merciaux. La page d'accueil du projet est situee a l'adresse http://www.microwindows.org. 
Ces bibliotheques sont diffusees sous MPL (MozMa Public licence, http://www.mozilla.org/ 
MPL), ce qui signifie que Ton peut baser des applications commerciales sur Micro Windows 
et Nano-X a condition que les modifications eventuelles sur les bibliotheques restent en 
Open Source. La bibliotheque Micro Windows utilise une API similaire a celle de Win- 
dows alors que Nano-X utilise un mecanisme client-serveur proche du fonctionnement 



Interfaces graphiques 

Chapitre 12 

de la Xlib sous XI 1. Meme si ces bibliotheques n'ont pas le niveau de fonctionnalite de 
Qt/Embedded ou GTK-Embedded, leur mise en place est tres legere et peut bien convenir 
a des applications graphiques simples. Notez qu'il existe une version Nano-X du naviga- 
teur Mozilla-0.9.4. 

Sous Linux, les bibliotheques peuvent etre utilisees sous XI 1, ou bien recourent au 
frame -buffer. L' archive est disponible a partir de la page d'accueil du projet et, une fois 
extraite, on obtient le repertoire microwindows-0.89pre8 (selon la version). 

La configuration des bibliotheques est situee dans le fichier src/conf ig et les valeurs par 
defaut generent une version frame -buffer. Si Ton souhaite generer la version XI 1, il faut 
modifier la ligne suivante : 

It X Window screen, mouse and kbd drivers 
Xll = Y 

Le support du frame-buffer est exclusif avec le support Xll. II est active au moyen des 
lignes suivantes : 

IFRAMEBUFFER = Y 

FBVGA = Y 

Dans tous les cas, la compilation s'effectue par une simple commande make. Les pro- 
grammes de demonstration sont ensuite disponibles sur le repertoire src/bi n. Dans le cas 
de l'utilisation de XI 1, le support de la souris est assure par X. Dans le cas de l'utilisation 
du frame-buffer, la solution la plus simple est d'utiliser le programme gpm, ce qui est 
d'ailleurs le comportement par defaut dans le fichier de configuration. 

GPMMOUSE = Y 



Attention 

Pour l'utilisation de la souris avec gpm, il est necessaire de lancer prealablement gpm avec la commande gpm 
R -t ps2. 



Pour tester le fonctionnement de Nano-X, on doit tout d'abord lancer le serveur, puis les 
clients. Dans l'exemple qui suit, nous utiliserons les clients nanowm (gestionnaire de fene- 
tre ou window-manager), nxterm (emulateur de terminal), nxcl ock (pendule) et ntetri s 
(jeu TETRIS). 

# cd src/bi n 

# ./nano-X & 

# ./nanowm & 

# ./nxterm & 

# ./nxcl ock & 

# . /ntetri s & 



Le resultat est indique dans la figure ci-apres. 
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Figure 12-7 

Demonstration de Nano-X. 

Plusieurs demonstrations de Micro Windows sont disponibles sur le meme repertoire. 
Si Ton fait : 

# ./mdemo 

on obtient l'ecran presente ci-apres : 




Figure 12-8 

Demonstration de MicroWindows. 
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Une bibliotheque d'affichage LCD: LCDproc 

Meme si les systemes embarques deviennent de plus en plus puissants, les applications 
industrielles n'ont pas toujours besoin d'un affichage complexe. Bon nombre de syste- 
mes se contentent d'un afficheur a cristaux liquides type LCD. Pour ce faire, le projet 
LCDproc (http://lcdproc.omnipotent.net) fournit une bibliotheque puissante, simple, et uti- 
lisable sur plusieurs afficheurs du commerce. En plus de cela, la bibliotheque fournit un 
pilote de test utilisant l'interface curses ce qui permet de mettre au point l'application 
sans disposer d'afficheur reel. 

Le principe de LCDproc est base sur une technique de client/serveur. Le serveur est 
charge d'effectuer 1' affichage sur l'ecran LCD et recoit pour cela les requetes des clients 
a travers un socket TCP sur un le port 13666. Par defaut le serveur et les clients sont exe- 
cutes sur une meme machine (soit localhost) mais rien n'empecherait d'effectuer l'affi- 
chage a travers Internet. 

La compilation de LCDproc ne presente pas de difficultes particulieres. Apres extraction 
de 1' archive, le mieux est de compiler le paquetage en incluant tous les pilotes d'ecran 
disponibles : 



$ ./configure 
$ make 



-enable-drivers=al 



Pour tester le systeme, il faut tout d'abord selectionner un pilote dans le fichier de 
configuration du serveur soit LCDd.conf. Dans notre cas, nous utiliserons le pilote de 
test curses. 

[server] 

# Server section with all kinds of settings for the LCDd server 

#Dri ver=none 

Driver=curses 

#Driver-rlD44780 

II faut ensuite executer le programme serveur dans un terminal comme suit. L option -s 
indique que 1' affichage des messages d'erreurs utilisera le demon syslog. 

$ ./server/LCDd -c LCDd.conf -s 
La fenetre prend alors 1' allure suivante : 



Figure 12-9 

Demarrage du serveur LCDproc. 
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On peut alors utiliser le client 1 cdproc fourni pour effectuer un test d'affichage. Ce client 
affiche l'etat du systeme en temps reel. 

$ ./cl ients/lcdproc/lcdproc 

Ce qui provoque l'affichage suivant : 



Figure 12-10 

Serveur LCDproc et client ledproc. 




II est bien entendu possible de piloter directement le serveur depuis un simple client 
telnet puisque nous utilisons le protocole TCP. La description des differents objets dis- 
ponibles est presente dans le fichier docs/netstuff .txt de la distribution LCDproc. 

Dans notre exemple nous effectuons une session telnet dans laquelle : 

• Nous initialisons le protocole LCDproc. 

• Nous creons un ecran d'affichage. 

• Nous creons trois objets title, string et scroller auxquels nous affectons des valeurs. 

Le texte en gras represente les commandes tapees par l'utilisateur, le reste du texte repre- 
sente les reponses du serveur : 

$ telnet localhost 13666 

Trying 127.0.0.1... 
Connected to localhost. 



Escape character is " 

hello 

connect LCDproc 0.4.5 

screen_add s 

success 

listen s 

widget_add 

success 

widget_set 

success 

widget_add 

success 

widget_set 

success 

widget_add 

success 

widget_set 

success 



]' 



protocol 0.3 led wid 20 hgt 4 cellwid 5 cellhgt 8 



s t title 



s t "Test LCDproc" 



s str string 



s str 1 4 Texte 



s scroll scroller 



s scroll 2 3 18 3 h 1 "Une ligne defilante" 
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La fenetre du serveur LCDproc a alors Failure suivante : 



Figure 12-11 

Serveur LCDproc et client telnet. 




Navigateurs et serveurs web 

Le navigateur web ou browser est de plus en plus utilise dans les applications industriel- 
les car il permet d'acceder a des equipements de maniere simple, conviviale, et indepen- 
damment de 1' architecture. Nombre de systemes embarques sont done equipes de serveur 
HTTP comme le programme Apache (http://www.apache.org) ou d'autres programmes 
serveur HTTP plus reduits en cas de systeme a faible empreinte memoire. Parmi ces pro- 
grammes, on peut citer Boa (http://www.boa.org) et MHTTPD (http://www.muquit.com/ 
muquit/software/mhttpd/mhttpd.html). Ces deux serveurs supportent les scripts CGI mais 
sont destines a recevoir un faible nombre de requetes par comparaison avec un programme 
comme Apache. L' utilisation pour une configuration a distance sera parfaitement adaptee. 

Dans le cas de systemes equipes d'interface graphique, il peut etre interessant d'utiliser 
un navigateur, soit parce que le systeme est destine a ce type de tache (set-top box ou 
terminal leger) ou parce qu'il sera plus simple de concevoir une interface basee sur des 
pages HTML, du JavaScript et des CGI que de developper une interface dediee. Dans ce 
cas, la meme interface sera disponible en mode local ou bien en mode distant, ce qui est 
tres interessant a bien des titres. Malheureusement, il faut admettre qu'un navigateur web 
« classique » est un composant extremement complexe, devant integrer un grand nombre 
d' extensions utilisees par les sites web actuels. Parmi ces extensions nous pouvons citer 
les frames (multi-fenetres), JavaScript, Flash, Java et les plug-ins divers et varies. Le sup- 
port de ces extensions conduit a une surenchere dans la complexite des navigateurs 
comme Internet Explorer 6 (IE 6) ou Nescape Communicator 6 (NS 6). Cette complexite 
entraine bien entendu les memes exces dans la consommation de ressources machines ou 
d'espace disque utilise, criteres une fois de plus peu compatibles avec un environnement 
embarque. 

Les navigateurs peuvent etre separes en deux categories. La premiere limite le navigateur 
a un outil de configuration du systeme local ou de systemes distants a vocation indus- 
trielle. Dans ce cas-la, le but est de presenter l'interface la plus simple et la plus efficace 
possible, et l'utilisation d'extensions lourdes et couteuses n'est certainement pas la 
meilleure solution. Le navigateur Lynx utilise une interface texte basee sur la bibliothe- 
que Curses citee au chapitre 5. II ne permet pas d'utiliser d'images mais supporte cepen- 
dant l'utilisation de scripts CGI. II est en outre dote de fonctions interessantes permettant 



Mises en ceuvre particulieres 

Troisieme partie 



d'automatiser certaines procedures qui utilisent le protocole HTTP. La page d'accueil du 
produit se trouve sur http://lynx.browser.org. 

Le navigateur Dillo (http://dillo.cipsga.org.br) est entierement ecrit en C et occupe environ 
200 Ko dans sa version binaire. Meme si Dillo n'inclut pas les memes fonctions, cette 
valeur soutient aisement la comparaison avec les dizaines de Mo necessaires pour un 
navigateur classique. Dillo utilise le toolkit GTK cite precedemment. II ne supporte pas 
pour T instant les frames mais il est tres rapide et peut etre tres bien adapte dans le cas de 
pages HTML a fenetre unique. La figure 12-12 donne un apercu du rendu graphique de Dillo. 
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Figure 12-12 

Le navigateur Dillo. 



Outre ces deux produits, la page WWW-Browsers for LINUX situee sur http://www.itp.uni- 
hannover.de/~kreutzm/en/lin_browser.htmldonne une liste impressionnante de navigateurs 
web utilisables sous Linux. 
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La seconde categorie concerne les navigateurs qui doivent s'approcher le plus possible 
des navigateurs classiques. Pour ces derniers, il est necessaire que les extensions graphi- 
ques multimedias citees precedemment soient disponibles. Ce type de navigateur equi- 
pera les systemes embarques du genre set-top boxes, terminaux legers ou PDA. Le defi 
est de taille car il n'y a pratiquement aucun standard ofhciel autour des extensions du for- 
mat HTML (a peine quelques « avis » du W3C concernant la compatibilite HTML). Le 
fait est que la loi est faite par ceux qui detiennent le marche du navigateur le plus 
repandu, en l'occurrence Microsoft avec IE. La logique de developpement des concep- 
teurs de pages graphiques est aujourd'hui simple : elle consiste a creer les pages avec des 
outils de conception dedies (la plupart du temps sous Windows) puis ensuite a tester 
exclusivement (ou presque) sous IE, ce dernier devenant done la reference absolue en 
maniere de compatibilite des pages. La tache des concurrents du navigateur IE n'en est 
que rendue plus ardue. 

II est un fait egalement que, si IE utilise plusieurs dizaines de Mo pour decoder toutes les 
extensions web, il sera bien difficile a un produit specialise « embarque » de faire exacte- 
ment la meme chose dans un volume environ 10 fois moindre. Dans ce domaine, la com- 
patibilite sera partielle, mais jamais totale, et e'est certainement une des raisons pour 
lesquelles la diffusion des consoles Internet et set-top boxes a toujours ete decevante par 
rapport au PC classique. II existe cependant quelques editeurs qui effectuent un travail 
remarquable sur le sujet. 

Le plus celebre est certainement Opera (http://www.opera.com) qui diffuse depuis plu- 
sieurs annees un navigateur multi-plate -forme (Linux, Windows, MacOS et autres) base 
sur la bibliotheque Qt. La version standard d'Opera a la reputation non usurpee d'etre 
extremement rapide par rapport a ses concurrents institutionnels. Opera est compatible 
JavaScript 1.3 et peut egalement utiliser le plug-in Java fourni par Sun Microsystems. 
La version 6.0 est disponible gratuitement en telechargement et l'editeur annonce deja 

I million de telechargements de la version Linux en mai 2002. Opera a depuis quelque 
temps investi dans la technologie embarquee en developpant une version dediee, basee 
sur Qt/Embedded. Opera annonce le produit comme tournant dans 3 Mo de RAM et 
occupant 1,5 Mo d'espace disque. Notez que cette version n'inclut pas le support de 
Java. Pour ce dernier, on devra utiliser une machine virtuelle externe comme le produit 
Jeode fourni par la societe Insignia (http://www.insignia.com). 

II est important de noter que le navigateur Opera n'est pas un produit Open Source et que 
son utilisation a des fins commerciales devra faire l'objet de paiement de redevances a 
l'editeur. Opera fournit cependant une documentation tres detaillee et certains compo- 
sants Open Source afin de permettre la personnalisation du navigateur en fonction des 
besoins de 1' application. Opera/Embedded est deja utilise dans plusieurs produits indus- 
tries comme le PDA Zaurus de Sharp ou bien le telephone Nokia 9210i. Une liste de pro- 
duits est disponible sur http://www.opera.com/embedded/products. Des versions de 
demonstration du navigateur Opera/Embedded sont egalement disponibles en ligne mais 
il est necessaire d'obtenir un code d'acces aupres de l'editeur. 
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En resume 

La majorite des applications embarquees sous Linux utilisent le mode texte. La console 
texte Linux peut tout a fait etre configuree tant au niveau des polices de caracteres que 
des claviers supportes. 

X Window System est le systeme graphique de predilection de Linux. La version 
XFree86-4 peut etre optimisee pour un environnement embarque en utilisant les fonctions 
VESA des chipsets graphiques. Lutilisation du frame-buffer permet d'acceder directement 
a des modes graphiques haute resolution a travers le noyau Linux sans forcement utiliser X. 
D'autres bibliotheques graphiques dediees comme Qt/Embedded, GTK-Embedded ou 
Micro Windows/Nano-X sont parfois mieux adaptees lorsque l'empreinte memoire 
necessaire est faible. D'autres composants comme LCDproc sont disponibles dans le cas 
ou 1' interface se reduit a la gestion d'un afficheur de petite taille comme un LCD. 

La technologie web basee sur le protocole HTTP et le langage HTML peut etre tres inte- 
ressante pour un systeme embarque configurable a distance. II faut alors l'equiper d'un 
programme serveur HTTP adapte. Lutilisation d'un navigateur web embarque peut se 
reveler complexe et couteuse si le systeme doit etre compatible avec les extensions mul- 
timedias des navigateurs classiques. 



Quatrieme partie 



Etudes de cas 




Cette derniere partie comprend deux etudes de cas reposant sur 
Linux et issues du monde industriel. La premiere etude concerne 
un Iecteur/enregistreur MP3 de salon entierement fait de compo- 
sants Open Source. La deuxieme etude presente un terminal de 
consultation Internet fonde sur une version adaptee de Netscape 
Communicator 4.79. Outre leur fonction initiale, ces deux 
projets permettent de decrire quelques techniques interessantes 
communement utiles dans le monde de Pembarque. 

Les composants et methodes traites dans ces etudes sont naturel- 
lement reutilisables dans d'autres projets industriels. 



13 



Open Music Machine 



Description du projet 

Le projet Open Music Machine (OMM) a pour objet de developper une platine de lec- 
ture/enregistrement evolutive, basee sur un systeme ouvert. II s'agit de realiser un sys- 
teme simple et convivial dont l'interface utilisateur sera similaire a celle d'une platine 
CD classique, toute la partie « informatique » devant etre masquee a 1' utilisateur. Le pilo- 
tage du systeme est entierement realise par une telecommande infrarouge et l'affichage 
est effectue sur un ecran LCD de faible dimension (4 lignes de 20 caracteres). Ce projet 
est typique d'une application embarquee et de 1' utilisation de composants Open Source. 
Differentes parties du projet, comme 1' API gestion des actions utilisateur ou la gestion de 
l'affichage LCD, sont reutilisables dans de nombreux projets similaires, tout le code 
etant diffuse sous GPL. 

L'idee initiale est d'utiliser des composants standards et peu couteux (architecture x86 
« grand public », systeme d' exploitation Linux, composants Open Source). Les principa- 
les fonctions envisagees pour OMM sont les suivantes : 

• lecture des CD audio avec affichage des informations par 1' acces a une base de don- 
nees de type CDDB (http://www.freedb.org, en cas de connexion reseau disponible) 

• lecture des fichiers MP3 

• creation de fichier MP3 a partir de fichiers audio extraits des CD 

• lecture de CD MP3 

• outil de navigation (selecteur de fichiers) 

• telecommande a infrarouge et gestion d'afficheur LCD 20 x 4 
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• connexion reseau de type Ethernet (cable ou ADSL) 

• client NAPSTER embarque 

• systeme d' exploitation multi-tache permettant de basculer d'une fonction a 1' autre 
lorsque c'est possible (par exemple : utiliser le selecteur de fichiers tout en ecoutant un 
morceau). 

D'autres fonctions, comme la gravure de CD-Rom MP3 ou de CD audio, sont facilement 
envisageables. Un mode de connexion reseau plus bas de gamme de type MODEM ou 
ISDN pourrait egalement etre envisage car nous avons vu au chapitre 6 que la mise en 
place d'une connexion PPP sous Linux etait simple et peu onereuse en espace disque. 
Une des caracteristiques du produit est la forte modularite et nous verrons plus tard que 
les fonctions sont realisees par de petits modules independants eux-memes geres par un 
module appele manager. En ce qui concerne 1' architecture materielle, il est egalement 
logique d'envisager plusieurs declinaisons du produit : 

• Une version minimale permettant de lire des CD audio ou MP3 mais ne disposant pas 
de disque dur. Ce dernier est remplace par un disque flash dont la taille ne permet que 
de stocker de tres faibles volumes (quelques fichiers MP3). Cette configuration se rap- 
proche de celle des baladeurs MP3 qui utilisent de la memoire flash (souvent au for- 
mat CompactFlash) pour stocker les fichiers MP3. II est d'ailleurs interessant de noter 
que ces baladeurs utilisent parfois de vrais systemes d' exploitation embarques indus- 
triels (cas du baladeur MP3 IOMEGA utilisant le systeme libre). 

• Le disque dur permet bien stir d'ajouter la fonction de stockage et done de gestion 
d'un catalogue de fichiers. Pour des raisons de compatibility entre les versions mate- 
rielles, le systeme d' exploitation (Linux) est systematiquement stocke sur la memoire 
flash, meme en cas de presence de ce disque. 

• La connexion reseau est optionnelle car elle ne concerne que la fonction d' identifica- 
tion des CD audio et celle du client NAPSTER (telechargement de fichiers MP3). 

Pour des raisons de cofit, toutes les fonctions sont realisees par des composants logiciels. 
Ce choix presente quelques inconvenients au niveau des performances (decompression 
ou compression MP3) mais permet une grande souplesse car un nouveau format ou une 
nouvelle fonction peuvent etre ajoutes tres facilement. 

Lors du demarrage du projet (en mai 2000), il existait deja plusieurs projets similaires ou 
meme des produits industriels. A de rares exceptions pres, ces projets existants ne sem- 
blaient pas satisfaisants car souvent trop proches d'un systeme informatique ou bien trop 
proches d'une platine CD classique. La presence d'une connexion reseau est extremement 
rare dans les produits de ce type alors qu'elle est a la base de l'utilisation de fonctions 
communicantes. Dans le cas de produits bases sur des composants materiels specifiques, 
l'absence de systeme d' exploitation evolue est la raison principale de cette limitation, 
ainsi que celle du manque d'evolutivite du produit. Ce dernier point correspond egale- 
ment a une realite economique (inciter le consommateur a remplacer son materiel) qui 
n'entrait pas en ligne de compte pour le projet OMM. 



Open Music Machine 

Chapitre 13 

Organisation du projet 

Le projet a ete developpe par deux personnes geographiquement « eloignees ». L'une fut 
chargee des aspects applicatifs, 1' autre ayant la responsabilite des aspects materiels et 
gestion des composants de type telecommande infrarouge, afficheur LCD ou systeme 
d' exploitation. Une seule version complete du materiel etait disponible (et pas immedia- 
tement) et il fut done necessaire de mettre en place une solution d'emulation permettant 
de developper la partie applicative sans disposer d'un materiel definitif. En optant pour 
un tel mode de fonctionnement, on peut aussi accelerer le temps de developpement et 
ameliorer la modularite du code. Pour passer d'un environnement de developpement 
a P environnement reel, il suffit de compiler les applications avec les pilotes materiels 
adequats. 

Les differents environnements de developpement furent les suivants : 

• Environnement de developpement sous XI 1, 1' afficheur LCD etant emule dans une 
fenetre X. La partie telecommande infrarouge est simulee par une application graphique 
rappelant la geometrie de celle-ci. 

• Environnement de developpement sous Curses, Pafficheur etant simule par une fenetre 
en mode texte et la partie telecommande par de simples raccourcis clavier. 

• Environnement reel utilisant les veritables pilotes infrarouges et LCD. 

Chaque environnement est associe a une bibliotheque dpy_HW . a (dpy_xll . a , dpy_curses . a, 
dpy_1cd.a) qui contient les fonctions de gestion des evenements utilisateur et de Paffi- 
chage LCD. Des informations generates concernant les interfaces graphiques embarquees 
sont disponibles au chapitre 12. 

Dans le cas du developpement dans 1' environnement XI 1, l'affichage LCD a Failure 
suivante. 
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Figure 13-1 

Afficheur LCD sous XI 1. 

Architecture globale 

Le systeme est base sur une version reduite de Linux similaire a celle decrite au chapi- 
tre 5. Dans ce type de systeme, le temps de demarrage est primordial car P utilisateur 
n'est pas habitue a un systeme informatique mais a un appareil electronique qui n' utilise 
pas de systeme d' exploitation evolue et done qui est operationnel des la mise sous ten- 
sion. Un systeme reduit du type de celui decrit au chapitre 5 a generalement un temps de 
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demarrage inferieur a dix secondes, auquel il faut cependant ajouter le temps d'initialisa- 
tion du BIOS de la carte, sur lequel nous avons tres peu de possibilites de configuration. 
Le cumul de ces deux delais peut parfois devenir critique et c'est la raison pour laquelle 
la version finale d'OMM utilise LinuxBIOS decrite au chapitre 8. Grace a LinuxBIOS, le 
temps de mise a disposition du systeme est reduit a quelques secondes mais cela oblige a 
utiliser une carte mere compatible. 

En raison des choix techniques et des contraintes mentionnees au debut de ce chapitre, 
1' architecture se devait d'etre extremement modulaire. II n'etait pas envisageable de rea- 
liser un logiciel unique charge de toute la partie applicative. De meme, toutes les couches 
logicielles devaient etre clairement separees afin de permettre 1' utilisation des differents 
environnements de developpement conduisant systematiquement a la generation de trois 
versions d'executables (XI 1, Curses et executables reels). L' architecture globale du sys- 
teme est decrite de facon schematique dans le diagramme qui suit : 




Figure 13-2 

Diagramme de V architecture globale. 



Les composants sont divises en trois categories : 

• Les composants applicatifs graphiques, qui effectuent des affichages sur le LCD. lis 
correspondent a la partie visible des differentes fonctions du systeme (lecteur CD, lec- 
teur MP3, encodeur MP3, selecteur de fichiers). 

• Les composants externes, qui n'utilisent pas d'interface graphique et qui sont en general 
issus de composants Open Source modifies pour OMM. Un exemple en est le celebre 
decodeur MP3 mpgl23. Ces programmes sont pilotes par les composants graphiques 
precedemment cites. 

• Le programme manager qui est charge de recevoir les actions utilisateur provenant de 
la telecommande infrarouge, ou bien de son simulateur, et de repartir les ordres aux 
differents composants graphiques. 

La communication entre ces differents modules utilise un composant Unix appele 
« tube nomme » {named pipe ou FIFO). Ce composant permet de mettre en place tres 
simplement un schema de type fournisseur/consommateur, ce qui explique l'analogie 
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avec le « tube » Unix (ou pipe) largement utilise dans toutes les versions a" Unix dont, 
bien sur, Linux. 



Rappel 

Le tube (symbolise par la barre verticale) est un composant qui permet de chainer des commandes Unix afin 
que la sortie d'une commande devienne I'entree de la commande suivante. On pourra par exemple compter le 
nombre de fichiers d'un repertoire en faisant 1 s -1 | wc -1. 

La difference entre un tube et un tube nomme reside dans le cote fugitif du tube classique 
qui n'existe que le temps de l'execution de la commande. Dans le cas du tube nomme, ce 
dernier est associe a un fichier special comme indique ci-apres. Nous remarquons que le 
premier caractere des attributs du fichier est la lettre p comme pipe. 

$ Is -la /tmp/ircd* 

prw-r--r-- 1 pierre users jan 29 2001 /tmp/ircd 

prw-r--r-- 1 pierre users jan 29 2001 

*»/tmp/ircd_reply 

Comme le montre la liste ci-apres, le principe a consiste a utiliser deux tubes nommes par 
fonction, l'un etant destine a la reception des commandes et 1' autre a la reponse, si neces- 
saire. Pour envoyer une commande a un module, il suffit done d'ecrire le caractere asso- 
cie sur le tube comme ci-apres : 

echo -n p > /tmp/ircd 

qui demarre le mode lecture (play) sur le module de lecture de CD audio. Au niveau de 
l'interface de programmation, un tube nomme sera facilement cree par les quelques 
lignes de code qui suivent : 

int open_fifo (char *fifo_name) 
{ 
int fd; 

/* Create if not existing */ 

if (mknod (fifo_name, S_IFIF0 | 0666, 0) != && errno != EEXIST) { 

log_err ("%s: %s" , fifo_name, strerror(errno) ) ; 

exit (1); 
} 

if ((fd = open (fifojame, 0_RDWR)) < 0) { 

log_err ("%s: %s", fifo_name, strerror(errno)) ; 

exit (1); 
} 

return fd; 
} 

Le descripteur ainsi calcule pourra ensuite etre utilise comme un descripteur de fichier 
classique. Comme indique sur le diagramme, le programme manager utilise des tubes 
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nommes (irmp3, ircd, etc.) afin de repercuter les ordres de l'utilisateur aux differents 
modules concernes. Les programmes graphiques ainsi que le manager sont geres par une 
petite bibliotheque evenementielle permettant de manipuler un automate a etats finis. La 
reception d'une commande (un caractere) dans un etat donne est associee a l'execution 
d'une fonction et au passage dans un nouvel etat comme le montre l'exemple expose 
ci-apres : 



static omm_event_handler cd_event_handlers[] = { 

'e', STATE_CD, cd_player_eject_close, I* 

'e', OMM_STATE_INIT, cd_player_eject_close, I* 

'p', STATE_CD, cd_player_play, /* 

'p'. OMM_STATE_INIT, cd_player_pl ay , /* 

's', STATE_CD, cd_player_stop, /* 



/" 



Open/close tray */ 



Open/close tray 
Play */ 
Play */ 
Stop */ 



'I 



"I 



OMM_DEFAULT_EVENT, 

0, 0, NULL 
}; 



OMM_ANY_STATE, cd_pl ayer_defaul t_handler. 



L'etat initial de l'automate est OMM_STATE_INIT. Si le programme detecte un CD dans le 
lecteur, il passera dans l'etat STATE_CD. En cas de reception du caractere e sur la FIFO de 
commande, le plateau du lecteur sera alternativement ouvert ou ferme par appel a la fonc- 
tion cd player_eject_close(), et l'etat passera done alternativement de 0MM_STATE_ 
INIT a STATE_CD. De meme, le demarrage de la lecture du CD par reception de/? (play) ne 
pourra se faire que si un CD est present (STATE_CD), et ce par appel a la fonction cd_ 
player_play(). 

La partie principale du programme initialise 1' API en lui passant la table des evenements 
et le nom du tube nomme a utiliser. Le troisieme parametre est une valeur booleenne 
indiquant la possibilite de pouvoir piloter 1' application depuis 1' entree standard (touches 
du clavier) et non seulement depuis le tube nomme. 

/* Init API */ 

omm_api_init (cd_event_handlers, CDPLAYER_FIF0, use_stdin); 

lcd_clear_screen (); 



/* 



"I 



I* Main loop */ 
omm_api_main_loop (); 

/* End */ 

log_debug (DEBUG_CDPLAYER, "exiting."); 

close_debug (); 

Pour le test en environnement de developpement, une solution simple et elegante consiste 
a developper un petit simulateur de telecommande en utilisant le langage Perl-Tk. Ce 
langage permet de construire rapidement des applications graphiques en recourant a la 
syntaxe du langage Perl (http://www.perl.org). Chaque touche affichee simule une touche 
de la telecommande et ecrit done un caractere particulier sur le tube nomme d' entree du 
programme manager. En fonction de l'etat de l'automate du manager, la commande en 
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question est ensuite executee. La figure ci-apres represente 1' interface de simulation de la 
telecommande. 



IR control 
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Figure 13-3 

Simulation de la telecommande. 

Outre 1' API de gestion des evenements, 1' API d'affichage sur le LCD doit egalement etre 
portable sur les trois environnements cible. La base de cet affichage est la fonction 1 cd_ 
writeO qui est independante de la cible. La fonction lcd_write() utilise elle-meme la 
fonction 1 cd_hw_write( ) qui elle est definie en fonction de renvironnement materiel de 
la cible. Dans le cas de l'environnement XI 1, cette derniere fonction se termine par un 
appel a la fonction XdrawImageStri ng( ) de la bibliotheque XI i b alors que, pour la cible 
Curses, on utilise la fonction classique mvprintw( ). 



Utilisation des composants externes 

OMM utilise exclusivement des composants Open Source et l'objectif etait de develop- 
per le moins de code particulier possible et done de s'appuyer sur des bibliotheques ou 
programmes existants. Cette approche a un but pedagogique evident, demontrant que 
l'Open Source peut reduire sensiblement le delai de developpement d'un produit. La liste 
des composants externes est brievement listee ci-apres : 

• libedaudio (http://cdcd.undergrid.net/libcdaudio) pour l'acces au lecteur de CD audio 
ainsi que la gestion des requetes a la base de donnees CDDB 
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• mpgl23 {http://www.mpg123.de) pour la lecture des fichier MP3 

• cdparanoia (http://www.xiph.org/paranoia) pour l'extraction des pistes d'un CD audio 

• gogo (http://homepage1.nifty.com/herumi/gogo_e.html), bladeenc (http://bladeenc.mp3.no) 
ou lame (http://www.sulaco.org/mp3) pour l'encodage MP3 

• nap pour le client NAPSTER (http://nap.sourceforge.net) 

• zgsmplay pour la base du selecteur de fichiers (http://rus.members.beeb.net/zgsmplay. 
html). 

A 1' exception de libcdaudio qui est une bibliotheque, les autres composants sont des pro- 
grammes independants qui sont utilises tels quels ou tres peu modifies. La principale 
modification apportee est l'ajout ou 1' amelioration d'une fonction de « pilotage a dis- 
tance » du programme depuis son entree standard. Des fonctions de ce type sont deja 
disponibles sur des programmes comme mpgl23 car leur pilotage a distance est assez 
couramment utilise. 

Cette methode permet de lancer la commande depuis l'applicatif graphique par un 
fork( ) suivi d'un appel a execlp( ) comme l'indique cet extrait du code du module de 
lecture MP3 : 



if (pipe (pipe_in) < 0) { 
log_err ("pipe_in: %s" 
exit (1); 



strerror(errno) ) ; 



if (pipe (pipe_out) < 0) { 
log_err ("pipe_out: Is", strerror(errno) ) ; 
exit (1); 



if (!(mpgl23_pid = fork ())) 
dup2 (pipe_out[0], 0); 
close (pipe_out[0]) ; 
dup2 (pipe_in[l], 1); 
close (pipe_in[l]) ; 
close (2); 



if (execlp (MPG123, MPG123, 
log_err ("execlp: %s: Is" 
exit (1); 



"-R", "-", NULL) < 0) { 
MPG123, strerror(errno) ) ; 



} 

Les options « -R - » indiquent a mpgl23 de travailler en mode pilotage a distance, ce qui 
signifie qu'il executera les differentes actions en fonction des commandes recues sur son 
entree standard et qu'il affichera le resultat sur sa sortie standard. Ce principe est tres 
pratique ici car 1' entree et la sortie standard du programme sont redirigees sur des tubes 
initialises lors de la creation du nouveau processus associe a mpgl23. Dans l'exemple 
qui suit, le dialogue avec mpgl23 est trace en mode pilotage a distance. Dans ce cas precis, 
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le programme est lance par un utilisateur dans un interpreteur de commande. Par conven- 
tion, les messages envoyes par le programme pilote commencent par le caractere @ . 

$ mpgl23 -R - 

@R MPG123 

L Eagles - Hotel California (Live Version) .mp3 

@I Eagles - Hotel California (Live Version) 

@S 1.0 3 44100 Joint-Stereo 365 2 1 112 

@F 15804 0.00 412.84 

@F 1 15803 0.03 412.81 

@F 2 15802 0.05 412.79 

@F 4 15801 0.10 412.76 

@F 4 15800 0.10 412.73 

@P 1 



Au lancement du programme, celui-ci affiche son identification. Cela peut etre mis a pro- 
fit pour verifier la version du programme. La commande L (load) tapee par 1' utilisateur 
indique au programme le nom du fichier MP3 a jouer ; mpgl23 retourne alors la ligne 
des ID3 tags contenant les caracteristiques du morceau suivies des parametres de l'enco- 
dage. Ces parametres pourront bien sur etre formates et affiches sur l'ecran du LCD. La 
suite des lignes @F constitue la progression de la lecture et sera egalement affichee. Si 
l'utilisateur tape le caractere p (pause/play), le programme repond @P qui indique l'etat 
de pause. En envoyant de nouveau unp, on poursuit la lecture jusqu' a la fin du fichier ou 
bien jusqu'a la reception du caractere q (quit). 



Detail des API 
Gestion des evenements 

La bibliotheque de gestion des evenements est tres simple, la taille du fichier principal 
omm_api .c etant inferieure a 80 lignes. Comme nous avons pu l'indiquer precedemment, 
la gestion des evenements est basee sur une structure definissant des pointeurs de fonc- 
tions associes a des actions operateur et a l'etat de 1' automate. Cette API est intimement 
liee a l'API de gestion de l'affichage decrite au paragraphe suivant. Les etats sont definis 
par la structure suivante : 

typedef struct _omm_event_handler { 

int code; /* event code */ 

int current_state; /* state before event */ 

void (*handler)() ; /* event handler */ 
} omm_event_handler; 

Les fonctions associees sont les suivantes : 
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oid omm_api_init (omm_event_handler *event_handler_tab, char *fifo_name, 
boolean use_stdin) 
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Cette fonction initialise l'interface a partir de la table des evenements tab et du nom du 
tube nomme fifo_name recevant les actions de l'operateur. La valeur booleenne use_ 
stdin indique si l'application peut recevoir des actions simulees depuis l'entree standard 
stdin (utilisee pour le test). 

void omm_api_close (void) 

ferme l'interface. De facon typique, ferme le tube nomme de communication. 

void omm_api_get_event (omm_api_event *ev) 
lit l'evenement en attente. 

void omm_api_handle_event (omm_api_event *ev) 

traite l'evenement lu precedemment. En l'occurrence, execute la fonction associee selon 
l'etat de 1' automate. 

void omm_api_main_loop (void) 

boucle infinie principale de gestion des evenements. Cette fonction utilise les deux fonc- 
tions precedentes comme suit : 

while ( !omm_api_end) { 

omm_api_get_event (&ev); 

omm_api_handle_event (&ev); 
} 
omm_api_event omm_api_get_current_event ( ) 

retourne la valeur de l'evenement courant. 

void omm_api_start_input (char *s, void (*fn_ok), void (*fn_abort)) ; 

initialise une saisie de l'operateur. La valeur sera stockee dans la chaine de caracteres s. 
La fonction associee au pointer fn_ok est executee en cas de validation de la saisie. La 
fonction associee au pointer f n_abort est executee en cas d'annulation de la saisie. 

char *omm_api_get_inpiit_str (); 

retourne la valeur de la chaine saisie. 



Gestion de Veer an LCD 

La bibliotheque de gestion de l'ecran presente une couche independante du materiel 
associee a une couche de bas niveau liee a ce materiel (1 cd_hw). Les sources de chaque 
bibliotheque d'affichage sont definies dans un fichier dpy_HW.c, HW correspondant au 
type d'interface materielle, soit : 

• 1 cd pour l'afficheur LCD reel 

• x 1 1 pour 1 ' emulation X 1 1 

• curses pour l'emulation Curses 
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Le fait d'ajouter un nouveau peripherique materiel (nouveau type d'ecran ou nouvelle 
couche d'emulation) se reduit a definir les fonctions suivantes : 

void lcd_hw_init (boolean use_stdin) 

Cette fonction effectue 1' initialisation materielle du peripherique d'affichage. Dans le cas 
de l'ecran LCD reel, cette partie contient en general des acces au port de controle du peri- 
pherique (souvent, port serie ou port parallele), comme l'indique l'extrait de code ci-apres : 

if(ioperm(P0RTADDRESS,3,D) {perrort "ioperm") ; exit(l);} 



pthread_mutex_init (&write_mutex, NULL) 
outbtinb(CONTROL) & OxDF, CONTROL); 
outb(inb(C0NTR0L) | 0x08, CONTROL); 
for (count = 0; count <= NB_COMMAND 

outb(init[count] , DATA); 

outb(inb(C0NTR0L) | 0x01, CONTROL) 

usleep(2) ; 

outbd'nb(CONTROL) & OxFE, CONTROL) 

usleep(2) ; 



count++) 



outb(inb(C0NTR0L) & 0xF7. 
/* ... */ 



CONTROL); 



Notez l'appel a la fonction iopermO qui permet a un programme en mode utilisateur 
d'acceder a des ressources normalement reservees aux pilotes de peripheriques. Cette 
solution est a utiliser avec precaution et il est en general preferable a terme de developper 
un pilote. 

Dans le cas de l'emulation XI 1 ou Curses, le code correspond a 1' initialisation de l'inter- 
face et de la fenetre, comme montre ci-apres pour la version Curses : 

initscr (); 
clear ( ) ; 
crmode (); 
noecho (); 
curs_set (0); 



xref = (COLS - 
yref = y = 3; 



22)/2; 



mvprintw (y++, xref, 

mvprintw (y++, xref, 

mvprintw (y++, xref, 

mvprintw (y++, xref, 

mvprintw (y++, xref, 

mvprintw (y++, xref, 
refresh (); 



curses_use_stdin = use_stdin; 
void lcd_hw_close (void); 
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Cette fonction ferme l'interface. L'exemple de Curses presente ci-apres indique un retour 
au mode d'ecran normal : 

tcsetattr(fileno(stdin), TCSANOW, &old_stdin) ; 
endwin (); 

void lcd_hw_write (int x, int y, char *s); 

Cette fonction ecrit une chaine de caracteres s aux coordonnees x et y de l'ecran. Elle est 
a la base de toutes les fonctions publiques d'affichage. 

int lcd_hw_input (void); 

lit un caractere venant de l'operateur (tube nomme). Dans le produit final, cela corres- 
pond aux actions de la telecommande. Dans ce cas, la telecommande est geree par un 
programme independant qui lit les trames infrarouges (venant en general d'un port serie), 
et formate la sortie en caracteres identiques a ceux envoyes par le simulateur xi r . pi . 

unsigned long lcd_hw_get_window(void) ; 

retourne un pointeur vers la fenetre d'affichage. 

Lorsque ces fonctions sont definies, l'API de gestion de l'affichage fournit les fonctions 
suivantes, definies dans le fichier 1 cd . c : 

void 1 cd_i nit (boolean use_stdin) 
initialise l'interface d'affichage (appel de 1 cd_hw_i ni t) 

void lcd_close (void) 
ferme l'interface d'affichage (appel de 1 cd_hw_cl ose) 

void lcd_dump_screen (void) 

affiche le contenu de l'ecran dans le fichier de trace. Cette fonction est utilisee dans les 
phases de test et de mise au point. 

void lcd_hide_screen (void) 

masque l'affichage de l'ecran courant. Cette fonction est utile pour passer une applica- 
tion en « arriere-plan » {background) comme cela est decrit plus bas dans le chapitre. 
L'affichage d'une fonction en arriere-plan ne s'effectue plus directement sur l'ecran mais 
dans un tableau de caracteres. 

void lcd_restore_screen (void) 
retour de l'application en avant-plan (foreground). Le contenu du tableau est affiche. 

int lcd_input () 
lit un caractere provenant de l'operateur (appel de 1 cd_hw_input). 

void lcd_write (int x, int y, char *s, lcd_attr attr) 
affiche la chaine de caracteres s aux coordonnees x et y de l'ecran en utilisant l'attribut attr. 



Open Music Machine 

Chapitre 13 

Les seuls attributs geres sont actuellement l'attribut d'affichage normal (ATTR_NORMAL) et 
clignotant (ATTR_BLINK). 

void lcd_write_center(int y, char *s, lcd_attr attr) 
affiche la chaine s centree sur la ligne y de l'ecran avec l'attribut attr. 
| void lcd_clear(int xl, int yl, int x2, int y2) 
efface une zone de l'ecran definie par deux points (xl, yl) et (x2, y2). 

void lcd_clear_screen(void) 
efface entierement l'ecran. 

void lcd_clear_l ineO'nt y) 
efface la ligne y. 

void lcd_init_hscrol 1 (void) 

initialise l'affichage d'une chaine de caracteres de longueur superieure a la largeur de 
l'ecran. 

| void lcd_write_hscrol 1 (int x, int y, char *s) 

affiche une chaine de caracteres s de longueur superieure a la largeur de l'ecran aux coor- 
donnees x et y. L'affichage est realise par un scrolling horizontal. 

void lcd_move (int x, int y) 
deplace la position courante d'affichage en x et y. 

void lcd_addch (int c, lcd_attr attr) 
affiche un caractere a la position d'affichage courante. 

void lcd_addstr (char *s, lcd_attr attr) 
affiche la chaine s a la position d'affichage courante. 

unsigned long lcd_get_window () 
retourne la valeur du pointeur de fenetre d'affichage (appel de 1 cd_get_hw_wi ndow). 

Arborescence des sources et compilation des modules 

Les sources sont organises de la maniere suivante : 

785 Dec 12 2000 Makefile 

219 Dec 11 2000 README 

4096 Jan 28 2001 auxprogs 

4096 Mar 6 13:44 ommprogs 

4096 Dec 29 2000 xi r 

Le repertoire auxprogs contient les programmes auxiliaires non graphiques recuperes a 
l'exterieur. Le repertoire ommprogs contient tous les modules graphiques ainsi que les API 
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susmentionnees (repertoire common). Le fichier Ma kef i 1 e de la racine utilise une fonction 
recursive afin d'explorer tous les sous-repertoires. 

SUBDI RS= ommprogs auxprogs 

all:: 
for i in $(SUBDIRS) ;\ 
do \ 

(cd $$i ; echo "making all" "in $$i..."; \ 
$(MAKE) $(MFLAGS) all); \ 
done 

Les API utilisant un environnement multi-cible, il est interessant de definir le fichier 
Ma kef i 1 e de maniere a generer automatiquement les differentes versions suffixees par le 
nom de la cible xl 1, led ou curses. L'exemple presente ci-apres decrit le fichier Makef i 1 e 
du module cdplayer. 

LIBDPYCURSES= libdpy_curses.a 

EXTRALIBSCURSES= -1 curses 

LIBDPYX11= libdpy_xll.a 

EXTRALIBSX11= -L/usr/XllR6/l ib -1X11 

LIBDPYX11= libdpyjcd.a 

EXTRALIBSLCD= 

MISCLIBS= -Icommon -ledaudio -Ipthread 

SRCS= cdplayer. c 

0BJS= cdplayer. o 

all: cdplayer_curses cdplayer_lcd cdplayer_xll 

cdpl ayer_curses : $(0BJS) . ./common/$( LIBDPYCURSES) . ./common/1 ibcommon. a 
$(CC) $(CFLAGS) -o $@ $(0BJS) -L.. /common -ldpy_curses $ ( EXTRALI BSCURSES) 
$(MISCLIBS) 

cdplayer_xll: $(0BJS) . ./common/$(LIBDPYXll) . ./common/1 ibcommon. a 

$(CC) $(CFLAGS) -o $@ $(0BJS) -L.. /common -ldpy_xll $( EXTRALI BSX11 ) $(MISCLIBS) 

cdplayer_lcd: $(0BJS) . ./common/$(LIBDPYLCD) . ./common/1 ibcommon. a 

$(CC) $(CFLAGS) -o $@ $(0BJS) -L.. /common -ldpyjcd $( EXTRALI BSLCD) $(MISCLIBS) 



Description des differents modules 
Module de gestion des fonctions (manager) 

Le manager est le noyau central de la gestion des fonctions d'OMM. Ce module recoit 
systematiquement les ordres de la telecommande via un tube nomme et redistribue les 
ordres aux differents modules en fonction de l'etat de 1' automate. Le premier role imparti 
a ce module est de selectionner la fonction active en appuyant sur Tune des six touches 
de fonction CD (lecteur de CD audio), MP3 (lecteur MP3), ENC (encodage de pistes 
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audio en compilations MP3), EDIT (edition des compilations), FSEL (selecteur de 
fichier), NAP (module NAPSTER). Lorsqu'un des modules est selectionne, un tube 
nomme par defaut est utilise pour diriger les actions de l'utilisateur vers l'application 
courante. La touche Quit de la telecommande permet de quitter l'application courante. 

Certains modules d'OMM peuvent coexister a un instant donne, une application appa- 
raissant en premier plan (foreground) et les autres en arriere-plan (background). L' appli- 
cation qui se trouve en premier plan est celle qui affiche les informations directement sur 
le LCD. Situee en arriere-plan une application affichera les informations dans un ecran 
« virtuel » qui sera copie dans le LCD si l'application revient au premier plan. Une illus- 
tration simple en est la possibilite d'utiliser le selecteur de fichier tout en ecoutant un CD 
audio ou bien un fichier MP3. 



Module de lecture des CD audio 

Le module de lecture CD cdplayer est base sur la bibliotheque libcdaudio. Cette biblio- 
theque diffusee sous GPL est tres simple a utiliser et elle est a la base d'utilitaires de 
lecture de CD sous Linux comme demcd. 

Une fois le lecteur CD ouvert, celui-ci est associe a un descripteur de fichier auquel on 
peut appliquer toutes les fonctions disponibles. 

if ((fd_cd = cd_init_device (CD_DEV)) < 0) { 

log_err ("Can't init device %s, exiting. \n", CD_DEV); 

exit (1); 
} 

On peut ensuite tester la presence du CD : 

int fd_cd; 

struct disc_info disc_info; 

if (cd_stat (fd_cd, &disc_info) < 0) 
log_err ("Can't stat CD"); 

if (disc_info.disc_present) { 

/* ... */ 
} 

puis effectuer des operations classiques comme la lecture, l'arret, la pause ou rejection 
duCD. 

if (cd_play (fd_cd, current_track) < 0) 
log_err ("Can't play CD"); 

/* ... */ 

if (cd_stop (fd_cd) < 0) 
log_err ("Can't stop CD"); 
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I* 



"I 



if (ccLpause (fd_cd) < 0) 
log_err ("Can't pause CD"); 



/* 



"I 



if (cd_eject (fd_cd) < 0) 

log_err ("Can't eject CD"); 

Ce module doit avoir les fonctions habituelles d'un lecteur de CD classique (voir les tou- 
ches de la telecommande) mais doit egalement pouvoir gerer les fonctions specifiques a 
OMM comme 1' interrogation de la base CDDB ou bien le marquage de pistes audio pour 
un encodage MP3 ulterieur. Dans le cas d'un fonctionnement compatible avec un lecteur 
classique, raffichage a l'apparence suivante : 



Figure 13-4 

Lecteur de CD audio. 



1 



HL 



CDfl SEL 

Track 00:59 03 
Length 07:04 
PLAY 



L' afflcheur LCD presente des informations classiques comme le numero de la piste, sa 
duree et sa position courante. On peut egalement afficher la duree totale du CD. Si OMM 
est capable d'interroger la base CDDB, il pourra recuperer des informations plus com- 
pletes comme le titre de 1' album, le nom de 1' artiste et les titres des differentes pistes. 
Sur la base CDDB, les informations sont indexees par une valeur numerique (Disc ID) 
codant de maniere unique le CD en cours d'utilisation. Pour limiter les acces a la base, 
ces informations sont ensuite stockees dans un espace « cache » sur le disque dur local. 
L' acces a la base CDDB est possible depuis la bibliotheque libcdaudio. A partir du cal- 
cul de l'identifieur du CD, on peut lire 1' information a partir du reseau puis l'ecrire sur 
le disque local. 

int disc_id; 

struct disc_data disc_data; 

disc_id = cddb_di rect_discid (disc_info) 

if (cddb_read_disc_data (fd_cd, &disc_data) < 0) 

log_debug (DEBUG_CDPLAYER, "Can't access CDDB for %x\" , disc_id); 
el se { 

if (cddb_write_disc_data (fd_cd, disc_data) < 0) 
log_err ("Can't write CCDB !"); 
/* ... */ 
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Une touche de la telecommande (Display) permet de commuter sur l'affichage de ce type 
d' informations si elles sont disponibles. L'afficheur presente alors les informations sui- 
vantes : 
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Figure 13-5 

Affichage d' informations CDDB. 

L'afficheur LCD etant de petite taille en largeur (seulement 20 caracteres), la bibliothe- 
que de gestion du LCD effectue un scrolling en temps reel. 

Comme il est egalement possible au moyen d'OMM d'encoder des pistes audio au for- 
mat MP3, le module de lecture CD permet done de « marquer » les pistes qui seront 
ensuite compressees par le module d'encodage encoder. Le marquage est effectue par la 
touche Mark/Unmark de la telecommande. Dans le cas de la selection d'une piste, l'affi- 
cheur a recours a un indicateur comme cela est decrit ci-apres : 
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Figure 13-6 

Selection d'une piste. 

II faut noter que l'indicateur de selection d'une piste est stocke dans le systeme, cette 
piste etant reperee de maniere unique par l'identifieur de CD et le numero de piste. On 
peut cependant annuler la selection de la piste en la selectionnant de nouveau, ce qui 
annule l'affichage de l'indicateur. 



Module de navigation/selection de fichiers 

Le selecteur de fichier permet de manipuler les fichiers MP3 generes a partir des pistes 
audio ou bien telecharges via le reseau. Grace a cet utilitaire, on peut selectionner un 
ensemble de fichiers qui seront ensuite lus par le module de lecture MP3 mp3player 
decrit plus bas. II faut noter que ce module peut etre execute en parallele avec d'autres 
modules comme la lecture CD ou MP3. On peut en effet manipuler des fichiers tout en 
ecoutant un CD ou des fichiers MP3. 
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Le module de selection de fichier fileselector est tres important pour un produit de type 
OMM car le fait de pouvoir generer un grand nombre de fichiers MP3 necessite done de 
disposer d'un outil pratique pour manipuler ces fichiers, sans oublier que l'interface 
d'affichage et de pilotage est rudimentaire par rapport a un systeme informatique (LCD 
20 x 4 et telecommande). Le probleme qui se pose est typique d'un systeme embarque, 
en P occurrence fournir une interface fonctionnelle conviviale dans un environnement le 
plus reduit possible. Developper un outil de ce type n'est pas forcement simple et le pro- 
gramme est done fortement inspire de la partie selection de fichiers de l'utilitaire zgsm- 
play destine a la lecture de fichier audio au format GSM via une interface texte basee sur 
Curses. 

Pour simplifier l'interface, OMM utilise un seul niveau de repertoire qui correspond aux 
noms des compilations creees par le module d'encodage MP3 decrit plus avant. En mode 
selection de fichiers, l'affichage a l'apparence suivante : 
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Figure 13-7 

Selecteur de fichiers. 

Ann de permettre l'utilisation d'un afficheur LCD quelconque, le curseur est entierement 
gere par la bibliotheque OMM. II est represente par le caractere > . La lettre D en debut de 
ligne indique un repertoire dans lequel on pourra entrer en appuyant sur la fleche droite 
de la telecommande. On retourne au niveau superieur en appuyant sur la fleche gauche. 
Lorsqu'on explore une liste de fichiers, on peut selectionner un fichier ou un repertoire 
entier en appuyant sur la touche de validation {Validate) de la telecommande. 



m 



Untitled 



12: 



i 04 - De Palmas - R 

• 04-Romeo_et_Juliet 

i 05_37_2LeHatin 

>une fols. .i'alme p 



Figure 13-8 

Fichiers selectionnes. 



Outre la selection de fichiers, OMM est egalement capable de manipuler les play lists 
contenant une suite de fichiers MP3 construite a partir de diverses compilations. On peut 
passer du mode fichier au mode playslist en appuyant sur la touche Dir/List de la tele- 
commande. 
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Modules de lecture MP3 

Le module de lecture MP3 mp3player est une interface au programme mpgl23, utilisee 
en mode pilotage a distance, comme decrit au debut de ce chapitre. L'avantage de ce 
mode de fonctionnement est double. II permet en premier lieu de s'affranchir de l'ecri- 
ture d'un programme complexe et de se concentrer sur la valeur ajoutee du produit que 
Ton developpe. Consequence corollaire, on peut profiter des evolutions du produit sans 
modifier son propre logiciel. Le deuxieme point important est la possibility de modifier le 
module en effectuant des retouches mineures sur le logiciel. Dans le cas present, il ne 
faut pas oublier que le format MP3 est soumis a des brevets (patent) et qu'il n'est en 
theorie pas legal d'utiliser mpgl23 dans un produit industriel dans de nombreux pays. 
L'utilisation d'un produit commercial officiel comme xaudio permet de resoudre le pro- 
bleme en effectuant dans ce cas-la aussi des modifications raisonnables. 

Le principe consiste a selectionner une liste de fichiers MP3 a jouer grace au selecteur de 
fichiers. Si Ton selectionne le module MP3 sur la telecommande, cette liste est automati- 
quement chargee dans le module. Au niveau de l'interface, le module a un aspect simi- 
laire a celui du lecteur de CD audio. 




Figure 13-9 

Module de lecture MP3. 

Les informations supplementaires concernant les caracteristiques techniques du fichier 
(frequence d'echantillonnage, bitrate, mode stereo/mono) ou bien les informations du 
type nom de 1' artiste ou du morceau constituent les ID3 tags (marqueurs ID3) et sont 
extraites du fichier par le programme mpgl23. On peut done obtenir un affichage de ce 
type: 
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STOP 



Figure 13-10 

Affichage des marqueurs 1D3. 
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Module d'encodage MP3 

Ce module permet d'encoder des pistes audio extraites de CD musicaux en fichiers au 
format MP3. Le systeme OMM ne disposant pas de systeme d'encodage materiel, cette 
action sera executee en plusieurs phases : 

• marquage des pistes a encoder comme indique precedemment, 

• extraction des pistes depuis les CD concerned et sauvegarde sous forme non compres- 
see (WAV) sur le disque, 

• encodage au format MP3 puis suppression des fichiers non compresses. 

Une phase intermediate avant l'encodage permet d'editer la liste avant de proceder a 
1' encodage. Cette fonction est realisee a l'aide du selecteur de fichier et est accessible 
depuis la touche EDIT de la telecommande. L' extraction des pistes est realisee grace a l'utili- 
taire cdparanoia livre en standard dans les distributions Linux. A partir d'une interface 
ligne de commande, 1' extraction est tres simple. 

# cdparanoia 1 piste_l.wav 

cdparanoia III release 9.8 (March 23, 2001) 

(C) 2001 Monty <monty@xiph.org> and Xiphophorus 

Report bugs to paranoia@xiph.org 
http://www.xiph.org/paranoia/ 
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outputting to piste_l.wav 
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La version standard du programme affiche la progression sous forme d'une ligne de texte 
utilisant le caractere >. Le symbole :-) (smiley) informe l'utilisateur du bon deroulement 
de 1' extraction. La modification apportee dans la version OMM est la possibilite de pilo- 
ter le programme a distance et de recuperer la valeur de la progression sous la forme @P 
pourcentage etat (exemple : "@P 51% :-)" ). Cette modification est aisee car, contraire- 
ment a mpgl23, cdparanoia ne necessite pas de dialogue complexe avec le programme 
appelant au cours de son execution. 

L'encodeur commence par demander le nom de la compilation qui sera associee aux 
pistes audio couramment selectionnees. La saisie des caracteres est un probleme pour ce 
type de produit car nous ne disposons pas d'un clavier reel. Le principe adopte ici est 
celui des telephones mobiles, et la telecommande contient done des touches numeriques 
couplees a des lettres. Pour entrer une lettre, il suffit d'appuyer autant de fois que neces- 
saire sur la touche associee. Pour passer a la lettre suivante, il faut utiliser la fleche 
qui se trouve a droite. Pour simplifier la saisie, le systeme ne gere que des lettres 
majuscules. 
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Figure 13-11 

Saisie du nom de compilation. 

Lorsque le nom est defini, le systeme demande successivement les CD associes aux dif- 
ferentes pistes a extraire. 
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Figure 13-12 

Insertion du CD. 

L' extraction des pistes s'effectue au fur et a mesure et les fichiers correspondant aux 
pistes audio sont stockes sur le disque dur sous forme de fichiers au format WAV. 



3: 



a: 



ENC 

thless - In Blue - 
EXTRACTING 
51% :-) . 



Figure 13-13 

Extraction d'une piste. 

Lorsque toutes les pistes sont extraites, les fichiers WAV sont compresses au format MP3. 
Pour ce faire, nous utilisons egalement un outil Open Source disponible sur Internet. II 
existe divers outils de ce type comme lame, bladeenc ou bien gogo. Originaire du Japon, 
ce qui explique sa sonorite quelque peu detonnante aux oreilles occidentales, gogo est de 
loin le plus rapide etant ecrit en bonne partie en langage assembleur x86. Les modifica- 
tions apportees sont la aussi mineures et concernent le pilotage a distance et Paffichage 
de la progression. Dans ce cas-la aussi, il serait tout a fait possible de remplacer un pro- 
gramme d'encodage par un autre a condition que celui-ci respecte V interface de pilotage 
definie par OMM. 

fifdef OMM 

percent=100*f rameNum/ total _f rame; 

printf("@P %d%%\n" , percent); 

fflush(stdout) ; 
#else 
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L'affichage est similaire a celui de l'ecran d'extraction. 
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Figure 13-14 

Encodage MP3. 

Modules client NAPSTER 

Le client NAPSTER est certainement le plus original du projet OMM. D'un point de vue 
conceptuel, NAPSTER vise a fournir aux utilisateurs une base de donnees qui indexe des 
milliers de fichiers musicaux MP3 repartis sur les postes des internautes du monde entier, 
ces derniers utilisant un programme « client » NAPSTER pour echanger ces fichiers. 
Bien que tres novateur, le concept ne fut pas du gout des grosses societes d' editions 
musicales et Ton peut aujourd'hui considerer qu'apres des annees de bataille juridique, 
NAPSTER est aujourd'hui bel et bien mort ! 

En nous en tenant au seul point de vue technique, il est sur que les concepteurs de NAPS- 
TER ont ouvert la voie a la notion de stockage reparti sur des postes clients a travers 
Internet. D'autres programmes similaires mais qui n'utilisent pas de base centralisee 
d'indexation (done difficilement « reperables ») sont aujourd'hui disponibles, par exem- 
ple Gnutella (http://www.gnutella.com). 

L'ajout d'un client NAPSTER a un produit de salon comme OMM est un deri, surtout en 
raison des limitations de l'affichage, les clients NAPSTER etant en general des applica- 
tions graphiques evoluees. Sous Linux quelques produits cependant utilisent une inter- 
face de type texte et une fois encore le principal travail consiste a ajouter une interface de 
pilotage a distance. Le client NAPSTER est base sur un programme Open Source appele 
nap dans sa version 1 .4. 

La version OMM du client NAPSTER est egalement limitee a du telechargement de 
fichier. Lorsqu'on clique sur la touche NAP de la telecommande, on obtient l'ecran suivant, 
qui indique le nombre de fichiers disponibles ainsi que le nombre de bibliotheques. 
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Figure 13-15 

Client NAPSTER. 
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Ce type de client a pour principale fonction d'effectuer une recherche en fonction d'une 
chaine de caracteres. En appuyant sur la touche Search de telecommande, on obtient 
l'ecran suivant : 
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Figure 13-16 

Recherche defichier. 

A cause de la limitation geometrique de l'afficheur LCD, les resultats de la recherche 
sont indiques un par un en indiquant la taille du fichier et le type de connexion. 
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Figure 13-17 

Resultat de la recherche. 

En telechargeant le fichier, on obtient l'ecran suivant 
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Figure 13-18 

Telechargement du fichier. 



On peut proceder au telechargement en menant en parallele une autre recherche. Comme 
dans un client NAPSTER classique, on peut revenir a l'ecran de telechargement en 
appuyant sur la touche Downloads. Les fichiers telecharges sont ensuite utilisables de la 
meme maniere que ceux qui sont encodes a partir de pistes audio. 
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En resume 



OMM est un exemple typique d'utilisation de Linux pour une application embarquee 
communicante. L' utilisation exclusive de composants Open Source permet de realiser 
facilement les fonctions recherchees en se basant sur des programmes existant en mode 
texte et en y ajoutant des couches de dialogue avec 1' application (pilotage a distance a 
travers des tubes nommes). La simulation de l'environnement reel dans un poste de deve- 
loppement Linux permet de mettre au point bien plus aisement l'interface. 

D"autres projets similaires sont aujourd'hui en cours, permettant egalement la lecture de 
fichiers video de type MPEG4 et DivX. Nous pouvons citer entre autres : 

• Le projet OM3 sur http://www.enseirb.fr/~kadionik/om-cube/om-cube.html 

• Le projet GeeXxBox sur http://www.geexbox.org/fr/screenshot.html 
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Dans ce chapitre, nous allons presenter la seconde etude de cas de cet ouvrage. II s'agit de 
realiser une station Internet basee sur le navigateur web Netscape Navigator version 4.79. 
La station en question est constitute d'une unite centrale de faible encombrement basee 
sur un processeur Cyrix MediaGX compatible x86. Le systeme utilise un clavier a infra- 
rouge integrant egalement la fonction de pointeur (souris). La figure suivante donne 
1' aspect exterieur du materiel utilise. Le systeme peut egalement mettre en oeuvre un 
couple classique clavier/souris, tous deux connectes sur des ports PS/2. 




Figure 14-1 

Aspect exterieur du systeme. 



Etudes de cas 

QUATRIEME PARTE 

Le travail realise est base sur les concepts decrits au chapitre 12 consacre aux interfaces 
graphiques. Le systeme peut etre configure a travers le navigateur pour les parametres de 
connexion, ce qui necessitera d'installer un serveur HTTP local. Le systeme utilise la 
version 3 de XFree86. 

Le present chapitre s'attachera a decrire les points suivants : 

• l'integration du navigateur sur le systeme, 

• la gestion du clavier et de la souris infrarouge, 

• l'integration du serveur HTTP local (boa), 

• la mise en place du systeme de configuration graphique. 

Nous considererons que le systeme est relie au reseau via une connexion Ethernet et ne 
traiterons done pas le probleme des connexions PPP. Ce dernier point est cependant traite 
en details au chapitre 6. 

Integration du navigateur 

Netscape Navigator est a ce jour le navigateur web le plus repandu sous Linux meme si 
Opera (http://www.opera.com) ou Mozilla (http://www.mozilla.org) deviennent des competi- 
teurs tres utilises. Le choix du navigateur n'a en fait que peu d' importance sur la logique 
d' integration sauf si nous en utilisons des particularites comme le pilotage a distance 
pour Navigator, decrit plus bas. Par rapport a Communicator, le terme Navigator indique 
la version programme qui integre uniquement la fonction de navigation web (navigator •_ 
standalone) et non les fonctions de courrier electronique et forums de discussion inte- 
grees par la version complete (complete _install). Le programme peut etre telecharge a 
1' adresse ftp://ftp. netscape, com/pub/communicator. 

Le probleme principal des navigateurs est l'espace me moire utilise tant au niveau du dis- 
que (ou de la memoire flash) que de la memoire vive. Meme Opera, le plus leger des 
navigateurs « complets », occupe plusieurs mega-octets d'espace disque s'il integre les 
extensions habituelles du langage HTML comme la gestion des frames, divers plug-ins 
ou, mieux encore, Java. Les utilisateurs desireux de ne pas utiliser de telles extensions, ce 
qui peut etre le cas d'une application industrielle dediee, pourront avantageusement 
s'orienter vers des programmes comme Dillo (http://clillo.cipsga.org.br), un navigateur 
Open Source tres leger (environ 200 Ko) et extremement rapide, deja cite au chapitre 12. 

Le fait est que 1' archive du navigateur stand-alone occupe deja 12 Mo en format com- 
presse. Lorsqu'on extrait cette archive sur un repertoire temporaire, puis que Ton utilise 
le script ns-install pour installer le navigateur, on obtient un repertoire cible occupant 
environ 22 Mo. 

I# du -s /opt/netscape/ 
22612 /opt/netscape 
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Si Ton regarde ce repertoire de plus pres, on peut decomposer le volume occupe assez 
facilement. 



# cd 


/opt/netscape 


# du 


-s * 


20 


LICENSE 


324 


Netscape. ad 


20 


README 


8 


XKeysymDB 


8 


bookmark.htm 


6872 


Java 


16 


1 ibnul lpl ugin-dynMotif .so 


408 


nethelp 


7568 


netscape 


5720 


netscape-dynMotif 


1616 


pi ugins 


4 


registry 


24 


vreg 



Si le plus gros element est bien l'executable netscape lui-meme (7,5 Mo), on peut deja 
s'affranchir de la version netscape-dynMotif qui occupe 5,7 Mo. Cette version permet 
de gagner 2 Mo si le toolkit graphique Motif est installe sur le systeme sous forme de 
bibliotheques partagees. Comme ce n'est pas le cas, nous utilisons l'executable netscape 
correspondant a la version statique de Motif et nous pouvons done supprimer la version 
dynamique. L' autre poids lourd est le repertoire java qui contient la machine virtuelle 
Java (JVM) fournie par Netscape. Si le support Java n'est pas necessaire, on peut done 
s'affranchir de 6,8 Mo de plus, mais il faudra invalider le support dans la configuration 
du navigateur. Le repertoire pi ugins contient en particulier le plug-in Flash permettant 
de visualiser les animations du meme nom. 

En resume, une configuration avec Java occupe environ 16 Mo, la meme sans Java envi- 
ron 10 Mo. Ces valeurs sont cependant assez importantes et nous avons choisi d'utiliser 
pour la partition contenant le navigateur le systeme de fichier compresse Cramfs decrit au 
chapitre 7. A partir du repertoire /opt/netscape, on peut generer l'image au moyen de la 
commande : 



# cd /opt 

# mkcramfs . /archives/netscape. img 



I 

L' archive ainsi creee ne fait plus que 10 Mo au lieu de 16 Mo. 

I# Is -1 /archives/netscape. img 
-rw-r--r-- 1 root root 10825728 jun 3 16:57 /arch 

Elle pourra etre montee sur la cible par la commande : 

# mount -t cramfs -o loop netscape. img /opt 
et integree dans le fichier /etc/fstabdela cible par la ligne : 

/archives/netscape. img /opt cramfs loop 



Etudes de cas 
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Le mode de demarrage depend de l'utilisation du systeme. Si celui-ci n'integre pas 
d'authentification par utilisateur (cas d'une bome interactive), l'interface graphique et le 
navigateur seront lances au niveau du fichier /etc/rc.d/rc.S decrit au chapitre 5 : 



# X GUI 

H0ME=/root 

USER=root 

cd $H0ME 

/usr/XHR6/bin/xinit 



-bpp 16 



# Reboot if exits from Navigator 
/sbin/reboot 

La commande xi ni t permet de lancer le serveur X en demarrant la liste de clients decrite 
dans le fichier .xi nitre du repertoire d'accueil. II fautnoter que la sortie de l'environne- 
ment X provoque 1' arret ou le redemarrage du systeme, ce qui est une bonne condition de 
securite. Dans notre cas, le fichier .xi nitre contient les lignes suivantes : 

# WM 
/usr/XHR6/bin/fvwm & 

# Navigator 
/opt /net scape/netscape 

Le gestionnaire de fenetre (ou window -manager) f vwm est tres leger (environ 100 Ko) et 
s'adapte tres bien a un environnement embarque. On peut egalement imaginer d'utiliser 
le navigateur sans gestionnaire en utilisant un mode plein ecran (appele aussi « kios- 
que ») mais cela peut poser des problemes en cas de creation de nouvelles fenetres par le 
navigateur et le mieux sera de mettre en place une gestion minimale des fenetres, au 
moins pour gerer leur superposition (avant-plan/arriere-plan). La configuration du navi- 
gateur Netscape en mode plein ecran se fait par 1' intermediate du langage JavaScript en 
utilisant le code suivant : 

<SCRIPT> 

open( ' http://www.google.com' , '_parent', 'location=no, menubar=no, resizable=no, 

** scroll bars=yes , status=no, toolbar=no, outerHeight=480, outerwidth=640, 

** screenx=0, screeny=0'); 

</SCRIPT> 

Cela permet d'ouvrir l'URL http://www.google.com en mode plein ecran 640 sur 480 pixels. 
Le mode plein ecran est parametrable par les arguments de la fonction JavaScript open. 
Si aucun element de controle n'est disponible (cas decrit ci-avant), il est possible de pilo- 
ter le navigateur a distance en utilisant l'option -remote de la commande netscape ou 
bien en utilisant le petit utilitaire remote. c disponible a l'adresse http://wp.netscape.com/ 
newsref/std/x-remote.html. Pour provoquer l'affichage de la boite de saisie d'une adresse, 
on fera : 

netscape -remote 'openURL(http://home. netscape. com) ' 

Ce systeme permet de mettre en place assez facilement une interface personnalisee 
entierement basee sur du code HTML. L action sur des boutons provoque l'appel au 
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programme de pilotage a distance. Ce fonctionnement est cependant propre au naviga- 
teur Netscape. 

Le langage JavaScript permet egalement de piloter une interface adaptee, et ce sur tous 
les navigateurs supportant ce langage. Lexemple presente ci-apres permet de gerer deux 
frames. Le frame superieur (appelee pub) contient la partie active de la page qui est 
modifiee en fonction de Taction sur un bouton de la partie inferieure (appelee menu). La 
partie menu peut egalement etre modifiee dynamiquement au cours de la navigation. 
Le code source du fichier racine i ndex. html se resume a la creation des deux frames. 

<FRAMESET R0WS="640,500" FRAMEB0RDER="1" B0RDER="1" FRAMESPACING=0> 

<FRAME NAME="pub" SRC="publ.html" SCROLLING=no> 

<FRAME NAME="menu" SRC="menu.html" SCROLLING=no> 
</FRAMESET> 

Le fichier publ . html contient seulement le code de test suivant : 

I<B0DY> 
Contenu apres action sur Menul 
</B0DY> 

Le fichier menu . html est une liste de pointeurs vers des pages provoquant la modification 
de la partie superieure. 

<B0DY> 

<TABLE> 
<TR> 

<TDXA HREF="menul.html">Menul</AX/TD> 
<TDXA HREF="menu2.html">Menu2</AX/TD> 
<TDXA HREF="menu3.html">Menu3</AX/TD> 
<TDXA HREF="web.html">Web</AX/TD> 
</TABLE> 
</B0DY> 

Le fichier menul . html contient uniquement le code JavaScript qui modifie les deux par- 
ties de l'ecran (fonction repl ace). Les autres fichiers de menu sont similaires. 

<SCRIPT> 

pa rent. pub. location. replace ("publ.html ") ; 

pa rent. menu. location. replace ("menu. html ") ; 

</SCRIPT> 

Dans notre cas, la partie menu reste inchangee, sauf si Ton clique sur le pointeur d'acces 
au web, soit le fichier web . html . 

<SCRIPT> 

parent.www_win = open( ' http : //l ocal host ' , '_blank', 'location=yes, menubar=no, 

** resizable=no, scrollbars=yes, status=yes, toolbar=no, outerWidth=640, 

*► outerHeight=440, screenx=0, screeny=0'); 

pa rent. menu. location. replace ( "web_menu.html ") ; 

</SCRIPT> 
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Dans ce fichier, une fenetre d'acces au web est creee dynamiquement et est nominee www 
win. Ce nom symbolique permettra ensuite de manipuler la page d'acces en utilisant 
d'autres fonctions JavaScript. La partie menu est maintenant modifiee en utilisant la page 
web_menu . html presentee ci-apres. 

<B0DY> 

<TABLE> 

<TR> 

<TDXA HREF="web_back.html">Back</AX/TD> 

<TDXA HREF="web_forward.html">Forwarcl</A></TD> 

<TDXA HREF="web_home.html">Home</AX/TD> 

<TDXA HREF="web_cl ose . html ">C1 ose</AX/TD> 

</TR> 

</TABLE> 

</B0DY> 

Cette page presente des boutons de pilotage de la page web, soit Back, Forward, Home et 
Close, ce dernier permettant de fermer la page d'acces web et de revenir au menu local 
(fonction cl ose). La page web_back. html est codee comme suit : 

<SCRIPT> 

parent.www_win.back( ) ; 

pa rent. menu. location. replace ( "web_menu.html ") ; 

</SCRIPT> 

Les autres pages sont similaires, mais la page web_cl ose . html retourne a l'ecran local et 
pointe de nouveau sur le menu initial. 

<SCRIPT> 

parent.www_win.close( ) ; 

pa rent. menu. location. replace ( "menu.html ") ; 

</SCRIPT> 

Ce petit exemple simple base sur des commandes JavaScript elementaires montre que 
Ton peut piloter un navigateur avec une interface tres reduite et peu gourmande en 
ressources. 



Gestion du clavier et de la souris infrarouge 

Le systeme peut utiliser un clavier infrarouge combinant les fonctions de clavier et de 
pointeur de souris. Cote unite centrale, le recepteur est connecte a un port serie qui mani- 
pule les trames du clavier sous forme d'une suite d' octets. Le but est de mettre en place 
un systeme permettant d'integrer la gestion de ce clavier a 1' interface X, et done au navi- 
gateur. Une solution possible est d'ecrire un module d'extension Xinput au serveur X. 
Cette extension permet d'ajouter dynamiquement des peripheriques d'entree au serveur. 
Elle est surtout utilisee pour gerer des tablettes graphiques et autres peripheriques de 
CAO. L'ajout d'une extension se fait au niveau du fichier de configuration XF86Config 
situe sur /etc/Xll. Les informations completes concernant ce type d'extension sont 
disponibles sur le serveur http://www.xfree86.org. Pour la version 4 de XFree86, le terme 
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Xinput est remplace par inputDevice et la syntaxe du fichier XF86Config est differente. 
Des informations interessantes sont egalement disponibles sur la page personnelle de 
Frederic Lepied a l'adresse http://people.mandriva.com/~flepied/projects/wacom. 

Le probleme principal que presente cette solution reside dans le fait qu'elle marc he 
uniquement sous X et pas en mode texte, or il est interessant de disposer d'un clavier 
(voire d'une souris) meme en mode texte. On va done traiter les donnees infrarouges 
dans un programme « demon » dedie, tournant en tache de fond et lance lors de l'initia- 
lisation du systeme. Le programme en question appele i rd (comme Infra Red Daemon) 
decode les trames clavier ou souris et les formate sous une forme comprehensible par 
le systeme. 

Traitement de la souris 

Le serveur XFree86 utilise le fichier de configuration /etc/Xll/XF86Conf ig dans lequel 
une section est reservee a la souris. La plupart du temps, cette section a l'apparence 
suivante : 

Section "Pointer" 

Protocol "PS/2" 

Device "/dev/mouse" 

EndSection 

On fournit comme parametres principaux le protocole utilise par la souris (ici PS/2) et le 
device associe a cette derniere. Dans un systeme classique, le device /dev/mouse est sou- 
vent un lien symbolique /dev/psaux qui correspond au pilote de gestion d'une souris, 
connecte au port PS/2 du PC. Le plus simple est done de fournir a XFree86 un flux de 
donnees correspondant a un protocole souris connu sur un device equivalent a /dev/ 
mouse. XFree86 reconnait un certain nombre de protocoles dont la liste est disponible 
dans la documentation du fichier XF86Config (man XF86Config). On peut citer entre 
autres : 

• Logitech 

• Microsoft 

• MouseSystems 

• PS/2 

• etc. 

Le protocole MouseSystems semble assez facile a utiliser ; il suffit de generer une trame 
de cinq octets a partir du numero de bouton appuye et des deplacements relatifs dx et dy 
du pointeur. 

char buffer[5] ; 

buffer[0] = (button A 0x07) | 0x80; 
buffer[3] = dx - (buffer[l] = dx/2); 
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buffer[4] = -dy - (bufferCZ] 
write (fd, buffer, 5); 



-dy/2); 



Pour le canal d' envoi des donnees, on peut utiliser un tube nomme comme cela est decrit 
dans l'etude de cas precedente. On cree le tube au moyen du code suivant : 

#define I R_F I FO "/dev/irmouse" 

if (mkfifo (IR_FIF0,0666) && errno != EEXIST) { 
log_err ("mkfifo: %s" , strerror(errno)) ; 
Exit (1); 



if ((fd_fifo = open (IR_FIF0, 0_RDWR|0_NONBLOCK) ) < 0) { 

log_err ("open: %s: %s" , I R_FI FO , strerror(errno) ) ; 

Exit (1); 
} 

On en deduit la nouvelle configuration du fichier XF86Config, tres proche de la prece- 
dente : 



Protocol 
Device 



"MouseSystems" 
Vdev/i rmouse" 



Traitement du clavier 

La gestion du clavier est plus compliquee meme si elle est similaire. Selon l'etat du sys- 
teme (en mode texte ou X), les donnees ne seront pas converties dans le meme format et 
n'utiliseront pas la meme technique d' insertion dans le systeme. II est cependant aise de 
connaitre l'etat du systeme en utilisant quelques fonctions bien choisies. Le code associe 
est en grande partie extrait du paquetage kbd qui fournit divers utilitaires de manipulation 
du clavier et de la console sous Linux. Nous rappelons que la configuration generale du 
clavier est decrite au debut du chapitre 7. 

A partir d'un descripteur de fichier f d_vt_stat associe a la console courante /dev/tty, 
on peut determiner le type de console (texte ou graphique). 

/* Determine la console virtuelle courante */ 
static int get_current_vt () 
{ 
struct vt_stat vtstat; 

if (ioctl (fd_vt_stat, VT_GETSTATE, &vtstat)) { 
log_err ("get_current_vt: VT_GETSTATE: Is", strerror(errno)) ; 
return -1; 

} 

return ( vtstat. v_acti ve) ; 
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/* Determine le type de console (texte/graphique) */ 

static int get_kd_mode () 

{ 

char buf [256]; 

int kdmode, current_vt; 

/* Teste si l'on est en mode console */ 
if ((current_vt = get_current_vt ()) > 0) { 
sprintf (buf, "/dev/tty&d" , current_vt); 

if ((fd_vt = open (buf, 0_RDWR)) < 0) { 
log_err ("open: %s : %s" , buf, strerror(errno) ) ; 
return -1; 

} 

if (ioctl (fd_vt, KDGETMODE, &kdmode)) { 

log_err ( "get_kd_mode: KDGETMODE: %s" , strerror(errno) ; 

return -1; 
} 

return kdmode; 
} 

return -1; 



Si la console est de type texte, on peut simuler Taction sur la touche d'un vrai clavier en 
utilisant la commande TIOCSTI sur le descripteur de fichier fd_vt associe a la console 
courante. 

| ioctl (fd_vt, TIOCSTI, (char*)&c); 

Le probleme se complique cependant un peu lorsqu'on doit gerer les modiricateurs de 
type Control ou Alt mais cela reste tres accessible. 

Si la console est de type X, nous utilisons l'extension XTEST du serveur X. Cette exten- 
sion permet de simuler Taction sur le clavier en envoyant des evenements X identiques. 
La presence de l'extension peut etre testee de maniere interactive grace a la commande 
xdpyinfo. 

1$ xdpyinfo | grep XTEST 
XTEST 

Le meme test peut etre effectue par programme. 

if ( IXQueryExtension (display, "XTEST", &major_opcode, &fi rst_event, &first_error) ) 

fprintf (stderr, "XTEST extension not available. \n" ) ; 
XCloseDisplay (display); 
exit (1); 
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L' envoi d'une chaine de caracteres par l'extension XTEST peut se faire en executant le 
code source suivant : 



char *string; 
Display *dpy; 
unsigned long delay 



0; 



KeySym ks = XstringToKeysym(string) ; 

XTestFakeKeyEvent (dpy, XKeysymToKeycode (dpy, ks), 1, delay); 

Une documentation complete concernant l'utilisation de XTEST est disponible en ligne 
a l'adresse http://ftp.xfree86.Org/pub/XFree86/4.0/doc/xtest. TXT. 



Systeme de configuration graphique 

Dans les chapitres 5 et 6, nous avons explique comment la configuration du systeme etait 
localisee dans des fichiers du repertoire /etc/sysconf i g contenant des variables d'envi- 
ronnement. Ces valeurs sont ensuite utilisees par les scripts de demarrages du repertoire 
/etc/red. Prenons ici l'exemple du fichier de configuration du reseau (fichier network), 
qui, rappelons-le, a la structure suivante : 

# Network configuration 

HOSTNAME=embtest 

DOMAINNAME=localdomain 

DEVICE=ethO 

IPADDR=192. 168.3.3 

GATEWAY=192.168.3.1 

NETMASK=255. 255. 255.0 

NETW0RK=192.168.3.0 

BR0ADCAST=192.168.3.0 

DNS1=62.161 .120.17 

DNS2= 

DAEMONS="xinetd" 

De la meme maniere, le fichier de configuration generale contient les lignes suivantes : 

I# General configuration 
KEYTABLE=fr 
KEYMAP=i386/azerty/fr-latinl 

Ces fichiers peuvent bien sur etre aisement modifies a l'aide d'un editeur de texte mais il 
est plus convivial et plus sur de donner la possibilite de modifier le parametrage au 
moyen d'un navigateur web. Le resultat se presente de la maniere suivante lorsqu'on 
ouvre la page de configuration sur le systeme. 
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Statistiques 



. 




Configuration reseau 




Figure 14-2 

Configuration du systeme. 

Une fonction de statistiques permet egalement de visualiser a distance l'etat du systeme 
en presentant de maniere plus elegante l'etat des indicateurs extraits de /proc. 



General 
Reseau 
Statistiques 
Arret 



Statistiques du systeme 



Systeme: Linux version 2.2.1 8 -new_i2c 

Duree actuelle defanctiannement: 7603588.68 secondes 

Type deprocesseur: : 8 model name : Pentium III (Coppermine) 

Occupation memaire (Kbytes) 



Libre 



Partagee 



Buffers 



144040 



Occupation casque (Mbytes) 



Casque 



5044188 4626176 



97% 



Temps utilisateur % Temps systeme % Temps libre % 



2i\ 




Capacite Monte sur 



Figure 14-3 

Statistiques du systeme. 
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Le parametrage est base sur l'utilisation de scripts CGI installes sur le systeme embar- 
que, ce qui necessite bien sur d'installer un serveur HTTP. Une methode similaire a deja 
ete utilisee au chapitre 10. 

La plupart du temps, les scripts CGI sont ecrits en langage Perl , en langage Python ou en 
TCL. Au vu de la simplicite des scripts, et dans un souci permanent de reduction de 
l'espace utilise, les scripts sont ici ecrits en langage de script shell car les interpreters 
/bin/bash ou /bin/ash sont deja installes sur le systeme. Concernant le serveur HTTP, 
nous n'utilisons pas le classique Apache (http://www.apache.org) livre en standard sous 
Linux mais le serveur reduit Boa (http://www.boa.org), largement suffisant dans notre cas 
et occupant seulement 50 Ko sur le disque. 

L'installation du serveur Boa est relativement simple mais la documentation est assez 
succincte. L' archive des sources est recuperable a partir de l'adresse http://www.boa.org. 
Une fois l'archive extraite, on peut compiler le programme en executant : 

$ cd src 

$ ./configure 

$ make 

$ Is -1 boa 

-rwxr-xr-x 1 pierre users 214130 Jun 4 18:03 boa 

$ strip boa 

$ Is -1 boa 

-rwxr-xr-x 1 pierre users 56188 Jun 4 18:03 boa 

Le programme peut etre ensuite installe sur le repertoire /sbin de la cible ; il sera de ce 
fait lance automatiquement au demarrage du systeme par le script /etc/rc.d/rc.inet2 
comme decrit au chapitre 6. Pour fonctionner correctement, Boa necessite la presence du 
fichier /etc/boa/boa . conf qui est similaire a celui d' Apache bien que plus simple. Pour 
le bon fonctionnement du serveur, il convient de s'interesser a quelques parametres de ce 
fichier. 

Le parametre Port definit le port TCP utilise par le serveur. La valeur par defaut est 80 
mais, si Ton teste Boa sur un systeme utilisant deja Apache sur le port 80, il faut impera- 
tivement modifier la valeur avant de lancer la commande boa. 

# Port: The port Boa runs on. The default port for http servers is 80. 

# If it is less than 1024, the server must be started as root. 

Port 80 

Les valeurs User et Group qui definissent les identifiants et groupes lors de l'execution du 
serveur sont en general fixees a nobody, valeur qui doit bien sur exister comme utilisateur 
et groupe dans les fichiers /etc/passwd et /etc/group de la cible. 

# User: The name or UID the server should run as. 

# Group: The group name or GID the server should run as. 

User nobody 
Group nobody 
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Remarque 

Pour des raisons evidentes de securite, il est fortement deconseille d'executer le serveur en tant que root surtout 
si Ton utilise des scripts CGI. 



Afin de permettre l'utilisation de scripts CGI en dehors du repertoire dedie a ces scripts, 
il est necessaire de valider 1' option suivante : 

I# Uncomment the next line if you want .cgi files to execute from anywhere 
AddType application/x-httpd-cgi cgi 

Concernant les traces de fonctionnement du serveur (log files), le fait d'utiliser un sys- 
teme embarque oblige a terme a limiter la taille des fichiers de trace, ou meme a envoyer 
ces traces sur le fichier poubelle /dev/null lorsque la phase de mise au point est ter- 
minee. 

# ErrorLog: The location of the error log file. If this does not start 

# with /, it is considered relative to the server root. 

# Set to /dev/null if you don't want errors logged. 

# If unset, defaults to /dev/stderr 

#Errorl_og /var/log/boa/error_log 
ErrorLog /dev/null 

Les documents HTML geres par Boa doivent etre places par defaut sur le repertoire /var7 
www. Lorsque la configuration du fichier boi.conf est terminee, le serveur peut etre teste 
en executant : 

§ /sbin/boa 

Si un fichier /var/www/i ndex. html existe et contient les lignes : 

I<B0DY> 
Hello world Boa! 
</B0DY> 

l'acces a l'adresse http://adresse_IP_du_systeme a l'aide d'un navigateur doit afficher 
Hello world Boa! 

Par defaut, les fichiers HTML et scripts CGI associes a la configuration du systeme sont 
installes sur /var/www/config. Le fichier index.html associe a ce repertoire est tres sim- 
ple, il correspond au resultat de la figure 14-2. II utilise uniquement deux frames HTML, 
la premiere correspondant au menu et la seconde presentant l'ecran d'edition des para- 
metres en fonction des choix dans ce menu. Cette fenetre est associee a un script CGI qui 
calcule dynamiquement le code HTML en fonction des fichiers de parametres du reper- 
toire /etc/sysconfig. Le code de la page principale est le suivant : 

<HEAD> 

<TITLE>Configuration du systeme</TITLE> 

</HEAD> 

<FRAMESET FRAMESPACI NG="0" C0LS="100,*"> 
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I<FRAME NORESIZE NAME="Menu" SCROLLING="auto" SRC="menu.html"> 
<FRAME NAME="Main" SRC="network.cgi "> 
</FRAMESET> 

Si Ton clique sur General, la page de droite affiche la configuration generale du systeme 
qui se resume pour 1' instant au choix du type de clavier. Nous allons detailler les scripts 
associes car ils sont beaucoup plus simples a apprehender que ceux de la configuration 
reseau, bien que la structure soit similaire. Le script general .cgi a pour but de lire le 
fichier de configuration general puis de presenter les informations du fichier dans la page 
HTML. Apres modification eventuelle des parametres par l'utilisateur, ces derniers 
seront sauves sur le fichier de configuration par le script set_general .cgi . 

Le debut du fichier correspond a l'envoi de l'en-tete standard utilise par les scripts CGI 
(les deux commandes echo). La ligne suivante permet d'evaluer les fichiers vari abl es et 
general dans l'environnement du CGI. Des lors, les valeurs des variables d'environne- 
ments definies dans ces fichiers sont disponibles au niveau du script CGI. 

#!/bin/sh 

echo Content-type: text/html 

echo 

. /etc/sysconfig/variables 

. $BASE/$GENCFG 

Nous rappelons que le fichier variable contient des lignes du type : 

I export BASE=/etc/sysconfig_test 
export NETWORKCFG=network 
export GENCFG=general 

En fonction de la valeur de la variable KEYTABLE, on determine le choix qui sera presente 
a l'utilisateur dans la page HTML dynamique. 

# Inits par defaut 
if [ "$ KEYTABLE" = "" ]; then 

KEYTABLE=fr 
fi 

# Lecture KEYTABLE 
case "$KEYTABLE" in 
fr) S_FR=SELECTED: ; 
us) S_US=SELECTED: ; 
*) S_FR=SELECTED; ; 
esac 

La suite constitue la generation dynamique du code HTML qui est realise par un simple 
cat sur la sortie standard laquelle, dans ce cas, correspond a la connexion reseau avec le 
navigateur. 
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cat « EOF 

<B0DY> 
<CENTER> 

<Hl>Configuration generale</Hl> 

</CENTER> 

<HR> 

<P> 

<F0RM ACTION="set_general . c g i " > 

<TABLE C0LS=2> 

<TR> 

<TD WIDTH=$MAXWIDTH>Type de clavier:</TD> 

<TD> 

<SELECT NAME="KEYTABLE" VALUE=" $KEYTABLE"> 

<0PTI0N $S_US>us 

<0PTI0N $S_FR>fr 

</SELECT> 

</TD> 

</TR> 

</TABLE> 

<P> 

<INPUT NAME=VALIDER TYPE=submit VALUE="Val ider la configuration'^ 

<INPUT NAME=ANNULER TYPE=reset VALUE=Effacer> 

</F0RM> 

</B0DY> 

EOF 

La page utilise une forme HTML qui permet de saisir les nouveaux parametres, puis de 
passer cette valeur sous forme de variable KEYTABLE au script CGI set^general .cgi 
associe a la forme lorsque l'utilisateur clique sur le bouton Valider la configuration. Cette 
technique a deja ete utilisee a la fin du chapitre 10 consacre a uClinux. La valeur de KEY- 
TABLE est passee a ce script au moyen de la variable d'environnement QUERY_STRING. 

Le script set_general .cgi doit extraire la liste des variables codee dans QUERY_STRING, 
et il utilise pour ce faire le code suivant base sur la commande sed (Stream EDitor). 

#!/bin/sh 

echo Content-type: text/html 
echo 

. /etc/sysconfig_test/ variables 



Etudes de cas 

QUATRIEME PARTIE 

# Lecture des variables 
if [ "$QUERY_STRING" != "" ]j then 

QUERY=~echo $QUERY_STRING | sed -e "s/=/=7g" -e "s/&/';/g" -e "s/+/ /g" 

* -e "s/$/V"- 
eval $QUERY 

Des lors, les valeurs des variables passees par QUERY_STRING sont disponibles dans l'envi- 
ronnement local du script CGI car, si nous avons une chaine du type : 

X=1&Y=2&Z=3 

dans la variable QUERY„STRING, le resultat de l'execution de la commande sed donnera le 
resultat suivant dans la variable QUERY : 

X='1';Y='2';Z='3' 

Apres evaluation par la commande eval, on obtient bien les valeurs de X, Y et Z dans 
l'environnement courant : 

1$ eval $QUERY 
$ echo $X $Y $Z 
1 2 3 

La suite du script CGI se contente de calculer le nom reel du fichier de description du cla- 
vier a charger, de sauvegarder les valeurs sur le fichier general et d'envoyer un message 
de confirmation ou d'erreur a l'utilisateur. 

case $KEYTABLE in 

fr) KEYMAP=i386/azerty/fr-latinl;; 

*) KEYMAP=i386/qwerty/us;; 

esac 

cat « EOF > $BASE/$GENCFG 

# General configuration 
KEYTABLE=$KEYTABLE 
KEYMAP=$KEYMAP 

EOF 

ERR=$? 

# Resultat 
if [ $ERR 1=0 3 ; then 

echo "<BODYXHl>Erreur ecriture config generale !</HlX/B0DY>" 
exit 1 
fi 

echo "<BODYXHl>Configuration enregistree K/H1X/B0DY> 



Station Internet 

Chapitre 14 

Pour que ce systeme fonctionne, le fichier /etc/sysconfig/general doit etre en acces 
lecture/ecriture pour l'utilisateur nobody utilise par le serveur Boa. II faut pour cela exe- 
cuter la commande chown nobody: nobody sur le fichier en question. Les erreurs d'acces 
sont tracees par defaut dans le fichier /var/log/boa/error_log. 



En resume 



La construction d'une petite station simple de consultation basee sur Linux embarque, 
X Window et un navigateur est relativement simple avec un peu de bon sens et en utilisant 
efficacement les composants du systeme. Ce petit exemple n'a pas la pretention de 
concurrencer une set top box professionnelle mais peut mettre sur la voie d'un projet reel 
plus ambitieux. 
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Glossaires en ligne 

II existe aujourd'hui un grand nombre de glossaires accessibles en ligne. Sur le sujet de 
l'embarque, nous pouvons citer les liens suivants : 

http://developers.cogentrts.com/cogent/cogentdocs/gl-timeglossary.html 

http://www.redhat.com/embedded/technologies/glossary 

http://www. rt. db. erau. edu/expehments/unix-rt/Glossary. html 

ainsi que des liens plus generaux : 

http://www.geocities.com/ikind_babel/babel/babel.html 

http://www.zytrax.com/tech/electronics 

http://www.cnet.com/Resources/lnfo/Glossary 

Glossaire local 

Ce petit glossaire non exhaustif reprend les definitions des principaux termes specifiques 
utilises dans cet ouvrage. 

API 

Acronyme anglais pour Application Programming Interface ou interface de programmation 
applicative. En general, cela signale un jeu de fonctions rassemblees dans une bibliotheque 
permettant de s'interfacer avec une couche logicielle donnee. 

Appel systeme 

Fonction accessible en mode utilisateur permettant d'appeler directement une fonction 
du noyau (exemple : getpid( ), qui retourne la valeur du processus courant). 

Appliance 

Terme anglais se traduisant par « serveur dedie ». En fait, designe un systeme dedie a une 
tache donnee (serveur web, terminal Internet). 
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Boot 

Demarrage d'un systeme informatique. 

Changement de contexte 

Actions accompagnant le passage d'un environnement d'un processus a un autre. 

Collaboratif 

Se dit d'un systeme multi tache dans lequel le noyau ne gere pas totalement le passage 
d'une tache a une autre. Les applications doivent alors rendre la main au systeme pour 
assurer le changement de tache. 

Deadlock 

En frangais, « etreinte fatale ». Situation de blocage sans limite de duree dans laquelle 
deux composants s'attendent mutuellement. 

Determinisme 

Se dit d'un systeme dont le comportement genere les memes resultats a partir du moment 
oil on lui applique les memes entrees. 

Device 

Terme general sous Unix qui designe un fichier « banalise » correspondant a une entree 
dans le repertoire /dev. On peut parler en frangais de « peripherique » mais le terme est 
moins general. 

Driver 

Terme anglais pour « pilote de peripherique ». 

Echeance temporelle 

Delai d'execution a respecter dans le cas d'un systeme temps reel a contraintes « dures » 
(hard real time). 

Embedded 

Terme anglais pour « embarque ». 

Enfoui 

Terme frangais pour « embarque ». Un systeme deeply embedded se traduit par « profon- 
dement enfoui ». 

Flasher/flashage 

Ecriture de donnees sur une memoire permanente de type memoire flash. On parle 
egalement de flasher un systeme lorsqu'on met a jour le logiciel residant sur une memoire 
flash. Le terme n'est pas tres elegant en frangais mais il est concis et efficace. 
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IPC 

Acronyme anglais pour Inter Process Communication (communication inter-processus). 
Designe un ensemble de composants logiciels permettant la communication entre des 
processus (memoire partagee, sockets, messages). 

JTAG 

Acronyme anglais pour Joint Test Advisory Group. La norme JTAG ou IEEE 1 149.1 permet 
de tester les parties numeriques des systemes, cartes electroniques et ASIC. 

Kernel 

Terme anglais pour « noyau », soit le coeur du systeme d'exploitation. 

Logiciel embarque 

Logiciel dedie au fonctionnement d'un equipement materiel dont la fonction principale 
n'est pas forcement le traitement de l'information. 

Memoire partagee 

Composant logiciel permettant de partager une zone de memoire entre plusieurs processus 
{voir IPC). 

MMU 

Acronyme anglais pour Memory Management Unit. Composant materiel charge de gerer 
la memoire d'un systeme informatique. 

Mutex 

Composant logiciel qui permet de synchroniser des processus legers (threads) en definissant 
des sections critiques. 

Ordonnanceur 

Algorithme fondamental d'un systeme d'exploitation multitache permettant le partage du 
temps entre les differents processus. 

Posix 

Acronyme anglais pour Portable Operating System Interface. C'est un ensemble de 
standards definissant le comportement de nombreux composants logiciels. 

Predictible 

Terme anglais. Se dit d'un systeme dont le comportement est previsible. Proche du deter- 
minisme. 
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Preemption 

Au niveau du systeme d' exploitation, ce terme s'oppose a « collaboratif ». Dans un systeme 
multitache preemptif, c'est le noyau qui decide d'interrompre une tache pour passer a une 
autre. Au niveau d'un noyau, on parle de preemption lorsque ce dernier peut interrompre 
une tache a n'importe quel moment arm de preserver l'ordre des priorites. 

Priorite 

Une valeur numerique qui definit l'ordre d'execution d'une tache par rapport aux autres. 

Processus 

Une tache, souvent un ensemble de processus legers ou threads. Sous Unix, chaque processus 
est identifie par une valeur entiere unique, appelee PID. 

Quantum de temps 

En anglais, time slice. Temps alloue a une tache dans un systeme d' exploitation. 

Ramdisk 

En francais, « disque memoire ». Permet d'utiliser la memoire vive comme une zone de 
stockage. 

Root filesystem 

En francais, « systeme de fichier principal ». Correspond au premier systeme de fichier 
(appele slash ou /) charge par le noyau, et indispensable au fonctionnement du systeme. 

RTOS 

Sigle anglais pour Real Time Operating System (systeme d' exploitation temps reel). 

Scheduler 

Terme anglais pour ordonnanceur. 

Semaphore 

Composant logiciel permettant de gerer l'acces exclusif a une ressource. 

Shell 

En francais, « coquille ». Sous Unix designe l'interpreteur de commande /bin/sh. 

Socket 

Composant de communication inter-processus le plus souvent base sur le protocole IP. II 
existe cependant des sockets dites « locales » n'autorisant la communication qu'au sein 
d'un meme systeme physique. 
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Temps partage 

Type de systeme d' exploitation pour lequel l'ordonnanceur privilegie le confort des utili- 
sateurs au detriment du respect des echeances temporelles. Le comportement d'un tel 
systeme n'est pas deterministe et le systeme ne peut done pas etre utilise pour des 
contraintes temps reel dures. Linux est un systeme de ce type. Les systemes a temps 
partage gerent tres mal les priorites entre les processus. On parle en anglais de time sharing. 

Temps reel dur 

A l'oppose du temps partage, un systeme temps reel « dur » {hard real time) est base sur 
la notion de priorite fixe. L'ordonnanceur a pour objet d' assurer le respect absolu des 
echeances temporelles. 

Temps reel mou 

Se dit d'un systeme qui doit repondre dans un temps raisonnable, « typiquement en X ms » 
ou « en moyenne en X ms ». 

Thread 

Terme anglais pour « processus leger ». Composant elementaire d'un processus. 

Tube 

Traduction de pipe. Element de communication inter-processus specifique a Unix. 
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Linux 

embarque 2 edition 

Linux, solution ideale pour les systemes embarques 

Discrets mais omnipresents, les logiciels embarques equipent aussi bien les appareils electromenagers et les 
vehicules que les assistants personnels et les telephones mobiles. Dans un contexte ou robustesse, legerete et 
interoperabilite sont essentielles, le systeme libre Linux se revele un excellent choix : Open Source et libre de droits, 
il peut etre adapte et diffuse a grande echelle pour un cout de licence nul, tout en integrant I'ensemble des 
dialectes Internet et multimedias. 

Un ouvrage de reference accompagne de deux etudes de cas 

Sans equivalent en frangais, I'ouvrage de Pierre Ficheux commence par un panorama du marche de I'embarque et 
des solutions Linux existantes en les comparant aux alternatives proprietaires. II indique la methodologie a suivre 
pour construire, a partir du noyau Linux, un systeme embarque adapte. Cette nouvelle edition traite egalement de 
la prise en charge du noyau 2.6 ainsi que de I'utilisation et la creation de chatne de compilation croisee (eldk et 
crdsstdol). Deux etudes de cas directement extraites de I'experience industrielle de I'auteur decrivent la construc- 
tion d'un lecteur/enregistreur CD/MP3 et d'une station de consultation Internet. 



Au sommaire 

Les logiciels embarques et leurs domaines d'application : Typologie des systemes embarques • Temps partage 
et temps reel • Panorama des systemes existants : VxWorks et pSOS, QNX, uC/OS (micro-C OS) et uC/OS II, 
Windows CE, LynxOS, Nucleus, eCos • Linux comme systeme embarque : Avantages et inconvenients • Systemes 
existants : compilation croisee ELDK/CROSSTOOL, RTLinux, MontaVista Linux, BlueCat Linux, uClinux, RTAI, 
ELDK • Applications : PDA, consoles multimedias et tablettes Internet, magnetoscopes numeriques, routeurs, 
telephonie, cameras IP, Freebox • Choix materiels : Architecture, PC ou non ? Processeur : MMU ou non ? Les 
processeurs compatibles x86. La memoire de masse • Les bus d'extension ISA et PCI • Ports serie et bus USB, 
I2C, 120, IEEE • Les cartes PC/104, DIL, uCsimm • Construction du systeme: Distributions classiques • 
Demarrage • Fichiers de configuration (/etc) • Pseudo-fichiers ou nceuds (/dev) • Programmes essentiels t/sbin 
et /bin) • Bibliotheques essentielles (/lib) • Repertoires variables (A/ar) • Partition dediee et repertoires • Le 
repertoire/extra, BusyBox • Configuration do reseao : Tests ICMP, TCP • Initialisation des interfaces locale et 
Ethernet • Services reseau • Optimisation do systeme : Authentification • Les systemes de fichiers : ext2/ext3, 
ReiserFS, JFFS2, CRAMFS • Techniqoes particolieres : Disques memoire • Demarrage LDADLIN • GDB et strace 

• Problemes de memoire • LinuxBIOS. RedBoot • Systemes temps reel • Systemes minimaox : pClinox • 
Deueloppement croise • Interfaces graphiqoes : Console standard (mode texte) • X Window System • Reduction 
du systeme • Serveur X minimal (Xkdrive) • Console graphique (frame-buffer) • Toolkits : Qt/Embedded et GTK- 
Embedded, Microwindows et Nano-X • Deox etudes de cas : Open Music Machine : Detail des API. Evenements 

• Ecran LCD • Arborescence des sources et compilation des modules • Gestion des fonctions, lecture des CD 
audio, navigation/selection de fichiers, lecture/encodage MP3, client NAPSTER • Station Internet. Integration du 
navigateur • Clavier et souris infrarouge • Configuration graphique. 



A qui s'adresse cet ouvrage ? 

- Aux developpeurs Linux et aux ingenieurs ayant a realiser des systemes embarques. 

- Aux decideurs et industriels ayant a choisir une solution pour leurs applications embarquees. 

Sur le site www.editions-eyrolles.com 

- dialoguez avec I'auteur; 

- telechargez le code source des etudes de cas ; 

- consultez les mises a jour et complements. 




Pierre Ficheux 

Ingenieur des Arts et 
Metiers, Pierre Ficheux est 
un linuxien de renom, 
initiateur de plusieurs sites 
Linux et auteur 
de nombreux tutoriels. 
II a trauaille entre autres 
chez Red Hat et s'est 
specialise dans les 
applications industrielles 
de Linux embarque. 
Pierre Ficheux est 
directeur technique 
d'Open Wide, societe 
spin-off de deux grands 
groupes industriels 
francais specialisee 
dans les technologies 
Open Source. 
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